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Preface 



The purpose of this manual is to familiarize the reader with the 
flow of control between major parts of the DX10 operating system, 
with the internal data structures used, and with the organization 
of the system disk. 

The manual is organized into the following sections and 
appendixes: 



Section 



: : Oi X*.: 

DX10 Implementation Tutorial — Describes the general 
concepts used throughout DX10 and control pathjs 
through major parts of DX10. ..-,.'' ..p i 

Organization and Structure of DX10 Source ' '7 j 
Libraries — Describes the organization . of the DXljO 
source disk, and includes a disk map. ■■■■>■ j 

System Loaders — Describes the software necessary tjo 
start up a DX10 system, including the boot loader^, 
disk loader, DX10 loader, and system restart task. } 

Disk Organization — Describes the physical and 
logical format of a DX10 disk, as well as the internajl 
structure of all file types that are supported. j 

i 
System Files — Describes some special files , used by 
DXlO. "" f I 

i 
Data Structures — Describes many of the -in-te-rnal-da^a 
structure built and maintained by DXlO. 

DXlO Data Base Modules — Describes the information 
contained in the two data modules within DXlO. 

Common System Routines — Names and describes the 
stacking and queueing routines used by many of the 
system routines. 

DXlO Source Modules — Contains a tabularized 
description of the most important modules in DXlO. 
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'10 System Command Interpreter — Describes the separate 
functional parts of the system command interpreter 
(SCI) and the flow of control between those parts. 



Appendix 

A System Crash Analysis — Briefly describes the methods 
for recovery from a system crash. 

B Regenerating DX10, SCI, SDSMAC, and XLE from the 

Source — Contains information for regenerating the 
elements of the operating system. 

C Scheduler Structure and Operation — Describes the 
DX10 task scheduler, including it's flow of control. 

A Device States and LUNO Assignments -- A short note 
describing LUNO assignments for devices in various 
states. 

E VDT Input Characters SVCs — A discussion of SVCs >08 
and >18. 

F System Level Debugger — Discusses entry into ttfl 
Debugger and the subcommands that you can use to debug 
a program. 



iv 939153-9701 



System Design Document 



Preface 



This manual assumes that the you have a detailed, working 
knowledge of the information contained in the" following DX10 
manuals : 



Title 

DX10 Operating System Concepts 
and Facilities (Volume I) 

DX10 Operating System 
Operations Guide (Volume II) 



DX10 Operating System 

Application Programming Guide (Volume III) 



DX10 Operating System 
Text Editor (Volume IV) 



DX10 Operating System 

Systems Programming Guide (Volume V) 

DX10 Operating System 

Error Reporting and Recovery Manual (Volume VI) 



Part Number 
946250-9701 
946250-9702 
946250-9703 
946250-9704 
946250-9705 
946250-9706 
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Section 1 
DX10 Implementation Tutorial 



1.1 GENERAL CONCEPTS 

The DX10 operating system is physically divided into two parts: 
one is memory resident and the other is disk resident. Memory 
resident DX10 includes: 

* System tables and device buffers 

* System overlay areas 

* Task scheduler 

* Task loader 

* Overlay loader 

* System overlay loader 

* XOP processors 

* Most SVC processors 

* Interrupt processors 

* Some system tasks that may have overlays (such as the 
disk manager or file manager) 

These parts are linked together during system generation, and 
loaded into memory when the system is loaded, forming the nucleus 
of DX10. 

Disk resident parts of DX10 include system overlays and some 
system tasks. System overlays are loaded into the system overlay 
areas reserved within the memory resident nucleus. System tasks 
are loaded into available memory and are mapped in, (share memory 
with the nucleus) . 

Figure 1-1 shows a simplified view of DX10 physical organization. 
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Figure 1-1 DX10 Physical Organization 
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The following paragraphs describe several important concepts used 
in the DX10 operating system. These include: 

* Queues 

* Queue Servers 

* Active Task Queue 

* Beets (32-Byte Blocks of Memory) 

* Calling Conventions 

* System Memory Mapping 

1.1.1 Queues 

A queue is a first-in, first-out list of data to be processed. 
In DX10, each queue consists of a queue anchor located in the 
memory-resident nucleus, and the queued blocks of data. Each 
block is linked to the next block in the queue (see Figure 1-2) . 

1.1.2 Queue Servers and Active Task Queues 

A queue server is a task that is dedicated to the processing of 
the data blocks in its associated queue. For example, the Bid 
Task SVC processor is a disk-resident task that is a queue 
server. The queue entries are buffered supervisor call blocks. 

A queue server operates in the following manner: when an entry 
is placed in the queue, the queue server is activated (bid) . The 
queue server, operating as a task under DX10 , dequeues an entry 
from its queue and processes it. The queue server continues to 
dequeue and process queue entries until the queue is empty, at 
which time the queue server suspends itself by issuing a Suspend 
Awaiting Queue Input SVC (code >24) . When a new entry is placed 
in the queue, the queue server is re-bid. 

Nearly all of the functions of DX10 are performed by queue 
serving routines. Many SVC processors such as I/O SVCs, Install 
Task, Kill Task, plus all of the disk-resident SVC processors are 
queue servers. 
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NOTE 

Disk-resident queue servers are pseudo-memory 
resident. When such a task terminates 
awaiting queue input, its memory is not 
released until it is required to load other 
tasks. At that time, the memory is released 
and the task must be reloaded the next time 
it is bid. 



1.1.3 Active Task Queue 

The active task queue organizes the active tasks within the 
system into priority order. This means that all tasks of the 
same priority level are grouped in a list, and these lists are 
then arranged so that the highest priority level list is at the 
top of the queue. The top task on each priority list is the 
oldest task on that list, and the bottom task is correspondingly 
the youngest. Tasks are then executed in order from the oldest 
task on the highest priority level, and ending with the youngest 
task on the lowest level of priority. The scheduler alway^ 
causes the top task on the active task queue to be in executio 
Figure 1-3 shows how the active task queue can appear. A list £ 
maintained on the queue for each priority level. Figure 1-3 
shows a queue in which priority levels Rl through R38 are void, 
level R39 has two tasks, R40 has one task, and level R41 has 
three tasks. The remaining real time priorities are void with 
level 1 having five tasks, level 2 having three tasks, and level 
3 having 5 tasks. 
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Figure 1-2 DX10 Queue Structure 
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Highest priority task 



Rl through R38 lists are void 



T1/R39 
T2/R39 



R39 list 



T3/R40 R40 list 

T4/R41 } 

T5/R41 J R41 list 

T6/R41 } 

< R42 through R127 lists void 



Lowest priority task 



T7/1 

T8/1 

T9/1 

T10/1 

Tll/1 

T12/2 
T13/2 
T14/2 

T15/3 
T16/3 
T17/3 
T18/3 
T19/3 



1 list 



2 list 



3 list 



T1,T2 

T3 

T4,T5,T6 

T7,T8,T9,T10,T11 

T12,T13,T14 



priority R39 
priority R40 
priority R41 
priority 1 
priority 2 



T15,T16,T17,T18,T19 priority 3 

Figure 1-3 Active Task Queue 



1.1.4 A 32-Byte Block of Memory — Beets 

Under DXlO memory management, a beet is defined to be a 32-byte 
block of memory. A beet address (boundary) is an absolute 
address that can be evenly divided by 32. The concept of a beet 
address is necessary to DXlO memory management in order to fit a 
20-bit absolute (unmapped) memory address into a 16-bit word. 
Memory is allocated by beets, and memory allocations begin on 
beet boundaries. 
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1.1.5 Calling Conventions 



Within DX10 , routines normally call each other using the 
following sequence: 

BL @SUBR 
DATA ERROR 
NORMAL EQU $ 

where SUBR is the entry label of the routine being called, ERROR 
is an address within the calling routine to which the called 
subroutine should return in case of an error, and NORMAL, the 
next instruction, is the normal (non-error condition) return 
point. 

Since the call is made using a BL instruction, Rll points to the 
word containing the error return address. The following sequence 
is generally used by the called subroutine, when returning. 

Put any error code in RO. 

If no error, do normal return. 

If error, return to address 

contained in word following 

the call. Normal return 

is to the second word 

after the call. 

Since the return sequence is often used in DX10, a special 
routine, POPO, is provided to perform the return (see Section 8 
on common system routines) . 





MOV 


@ERRCOD,R0 




JEQ 


RTNORM 


ERRET 


MOV 


*R11,R11 




RT 




RTNORM 


INCT 
RT 


Rll 
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1.1.6 System Memory Mapping 

Using the memory mapping option available with 990 type hardware, 
the DX10 operating system is divided into several different 
mapping schemes using map files and 1 (Figure 1-5) . This is 
necessary since the physical memory size of DX10 exceeds 64K 
bytes. The mapping schemes link together segments of the memory 
resident operating system (Figure 1-4) to perform different 
tasks. 

All mapping schemes include the DX10 data base, system table 
area, and common system routines (called the system root) as the 
first segment (memory mapping allows a program to be divided into 
three segments which need not be in contiguous memory locations) . 
All schemes which use map file have the I/O common routines 
(routines commonly used by device service routines) as the second 
segment. The third segment of all map file schemes is one of 
the following: 

* The task scheduler and SVC and XOP code 

* A device service routine (DSR) . 

Figure 1-6 shows how the logical address space of map file J 
schemes is arranged. 

In one of the map file 1 schemes, file management and key indexed 
file handling code are physically located in memory immediately 
after the system root in the first segment. This map scheme 
allows file management to map I/O buffers into its address space 
using the two remaining map segments. 

Other map file 1 schemes include either a system task (memory 
resident or disk resident) or system common as the second 
segment. The third segment is available for use by the task. 
Figure 1-7 shows possible arrangements of map file 1 schemes. 

The link map of a generated system contains information on 
exactly which DX10 modules are included in each mapped segment. 
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1.2 FLOW OF CONTROL THROUGH DX10 



The flow of control through DX10 follows various paths, depending 
on the action currently being performed. The remainder of this 
section traces these control paths separately, following the 
general order of events caused by the execution of a task. The 
order begins with SVC processing and the task bid and ends with 
task termination. 



1.2.1 SVC Processing 

Under DX10 , SVCs are implemented as extended operation (XOP) 15. 
When an SVC is issued, control is passed via the XOP trap vector 
table to the SVC decoding routine, SVC INT, which is the XOP 
processor for XOP 15. This routine determines which SVC is 
desired (by decoding the SVC code in the call block) , and oasses 
control to the SVC processor . 

If the SVC processor is a queue server, control passes from 
SVCINT to the SVC buffering routine, SVCBUF. This routine 
buffers the call block into the system table area and queues the 
buffered call block on the proper queue, thereby activating the 
associated queue server task. The task that issued the SVC is 
suspended. 

If the SVC is for I/O (code >00) , the SVC goes through another 
stage of decoding by the I/O supervisor, DXIOS. This routine 
buffers the user I/O data block and supervisor call block into 
the system table area, and determines whether the call is for 
file management (disk file I/O), file utility, or device I/O. 
File Management and File Utility calls are queued for the file 
management task or file utility task, respectively. Both are 
queue servers. Device I/O requests are handled by DXIOS and the 
device service routine directly, if the device is not busy. If 
the device is busy, the request is queued in the device queue for 
later processing. 

The return of control to the task that issued the SVC is 
different for queue serving SVC processors and nonqueue serving 
processors, non-queue servers simply return control to the 
calling task via the system return point XOPRTl, allowing the 
calling task to resume execution. Queue servers do not 
immediately return control to the calling task, but continue to 
process queue entries. When an entry has been processed, it is 
queued for the SVC cleanup routine, SVCCLN. SVCCLN unbuffers 
each entry from the system table buffer into the calling task's 
memory, releases the system table area, and reactivates the 
calling task. Figure 1-8 shows the flow of control through the 
DX10 modules involved in SVC processing. 
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1.2.2 Bidding a Task for Execution 

The DX10 operating system bids a task for execution by: 

* Building the task status block (TSB) , 

* Queueing the TSB for processing by the bidder task, 
TM$BID, 

* And then queueing the TSB for the task loader. 

This process is described further in the following paragraphs, 
and is shown in Figure 1-9. 
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Figure 1-9 Bidding a Task 
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The first action taken by DX10 when bidding a task is to build a 
TSB. A TSB is a block of overhead data maintained by the 
operating system to describe each task currently running (either 
executing, waiting for CPU time, or rolled-out) . The TSB 
contains pointers to other system overhead blocks associated with 
a task. These blocks include the logical device tables (LDTs) 
for each LUNO assigned by the task, procedure status blocks 
(PSBs) for any attached procedures, as well as other information 
describing the task to the operating system. See the section on 
data structures for more detail on TSBs and PSBs. From the time 
a task is bid until it terminates, the task is represented within 
DX10 by its TSB; all actions taken by the system in order to 
execute the task, such as roll-in, roll- out, and memory 
allocation, reference the TSB. 

To build a TSB, the system routine TMBIDO in module TM$ROT calls 
memory management to reserve a block of memory from the system 
table area. TMBIDO then initializes some of the fields in the 
TSB, generates a run-time ID for the task, and queues the TSB for 
further processing by the bidder task TM$BID. 

The bidder task, TM$BID, is a memory resident queue server for 
the bidder queue and the read/write queue. It performs the 
following functions: 

* Dequeues a TSB from its queue, 

* Fills in priority and other fields 

* Fills in pointers to various procedure status blocks 
(PSBs) , 

* Queues the TSB on the waiting on memory (WOM) queue. 

After dequeueing a TSB, TM$BID fills in several of the task's 
fields, including the priority field, using data from the program 
file on which the task is installed. The bidder task also fills 
in the "family tree" pointers in the TSB. These four pointers 
link the newly bid task with other tasks, according to the 
structure shown in Figure 1-10. Notice that all of the tasks 
shown have pointers linking them in a relational manner to each 
other. The parent task is the original task that issued the 
Execute Task SVC to bid the current task. If the current task 
was bid from a terminal through an SCI command, SCI is the parent 
task. The brother tasks are other tasks that were bid by the 
same parent task. The oldest son is the first task bid by the 
current task. (This pointer is given a zero value when the task 
is first bid.) 
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Other pointers that are initialized by the bidder task aR, 
pointers to the procedure status blocks (PSBs) for the procedures 
associated with the current task. A PSB serves a similar 
function for a procedure as a TSB does for a task. However the 
PSB pointers are not as complex as those for the TSBs. (See 
Section 6, Data Structures, for more details on PSBs). If a 
procedure attached to the task being bid is not currently in 
memory (that is, it does not have a PSB), the bidder task gets a 
block of system table area and builds the PSB for the procedure; 
the bidder task accesses the program file for necessary 
information. Figure 1-11 shows how TSBs and PSBs are linked by 
pointers under DX10 . Note that PSBs may be linked with more than 
one TSB, since a single procedure may be attached to more than 
one task. 
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Figure 1-11 TSB/PSB Relationship 
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Finally, the bidder task queues the TSB on the waiting on memory*' 
(WOM) queue which is serviced by the task loader. The bidding 
task (parent task) , which had been suspended while TM$BID 
processed the Bid Task SVC, is reactivated. 

The scheduler and operating system provide a means for tasks to 
be bid from interrupt processors. The bid-task interrupt 
processor : 

* Resets the interrupt, 

* Rets the bid-task-in-progress flag of the associated 
physical device table (PDT) , 

* Saves the ID of the task to be bid (the task to be bid 
must reside in the system program file) , 

* Sets up the processor interrupt vector for handling 
multiple interrupts before the first bid is complete, 

* Sets the reenter me flag, and 

* Returns via an RTWP instruction. 

Every time the scheduler runs, (every 50 milliseconds), it scan^i 

the the PDT list for reenter me flags, so that when the scheduler 

executes, the interrupt processor is reentered and the scheduler- 
inhibit flag (TM$EXT) is cleared. 

When the processor is reentered, all lower interrupts are 
disabled. The scheduler resets the reenter me flag before 
reentering the DSR. The interrupt processor initializes the 
registers required, and calls TMBIDO to bid the required task. 
When TMBIDO returns to the interrupt processor, the processor 
checks the returned error code. If the code is non-zero, then 
the bid did not work, and any appropriate action may be taken; 
when the error code is zero the bid worked, and the processor can 
return to the system. 
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To exit the processor because of an error or bid complete, the 
bid-task-in-progress flag is reset and the interrupt entry vector 
is set up for processing subsequent interrupts. Exit is made by 
an RTWP instruction which returns to the scheduler for any 
necessary scheduling. The following list contains register 
definitions for a call to TMBIDO: 

RO = Error Return 

Rl = Installed ID/SVC flag 

SVC flag: = SVC call 

NOT = Not an SVC call 
R2 = Bid Parameter #1 

R3 = Bid Parameter #2 

R4 = Station ID/Program File LUNO 

R5-R9 = Not used 
RIO = Stack Pointer (The Scheduler Stack 

is used.) 
Rll = Branch and Link Return Address 

R12-R15 = Not used 

The following list contains register definitions upon return from 
TMBIDO: 

RO = Error Return 

Rl = Run ID/ QUE - NO QUE flag (Bit 15) 

Bit 15: = Request not queued, 
1 = Request queued 
R2 = TSB address of bid task 

R3-R15 = Not used 

The following error codes can be returned from TMBIDO: 

= No error 

1 = Illegal station number on bid task 

2 = No runtime task IDs available 

3 = No system table area available 

4 = Illegal program file LUNO 

1.2.3 Scheduling, Loading, and Rolling a Task 

Once a task has been bid and a TSB has been built for it, that 
task must be loaded into memory before it can be scheduled for 
execution. The loading and executing of multiple tasks is 
managed by the task scheduler in conjunction with the task loader 
and memory management. 
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1.2.3.1 Scheduling. Tasks running under DX10 assume a variety 
of states, including: active, suspended, queued for a SVC 
processor, and waiting for various types of I/O. TSBs of tasks 
that are waiting for CPU time (active tasks), and are in memory, 
are queued on the priority-ordered active queue. The task 
scheduler always picks the highest priority task off the active 
queue. Before actually giving the CPU to this task, the 
scheduler first checks the queue of tasks waiting on memory. 

The waiting on memory queue is a priority-ordered queue (highest 
priority first) of the TSBs of tasks which are either rolled-out 
or have just been bid, and are waiting to get memory in order to 
execute. The scheduler determines if any task waiting on memory 
is of higher or equal priority to the task it has chosen from the 
active queue by searching the TSBs in the waiting on memory 
queue. If a higher priority task is waiting, and the task loader 
is not busy, the scheduler gives the next time slice to the 
loader rather than the chosen task. If an equal priority task is 
waiting for memory, and the chosen task has already had a minimum 
number of time slices, the loader is likewise awarded the time 
slice. Otherwise, the chosen task gets the time slice for CPU 
access. 

Figure 1-12 shows a simplified version of howthe scheduler 
chooses a task to execute. The scheduler is described in morC 
detail in Appendix C. 

1.2.3.2 Loading And Rolling. The task loader is responsible for 
loading tasks into memory and rolling them out. Tasks that are 
to be loaded may be either rolled-out tasks or tasks that have 
just been bid. The TSBs of all tasks to be loaded are on the 
waiting on memory queue. The queue is sorted so that higher 
priority tasks are processed first. For tasks of the same 
priority, the queue is first-in, first-out. 

Memory management usually selects and rolls-out tasks, (see 
paragraph 1.2.3.3). However, the task loader rolls-out tasks in 
2 situations: 

* The task has been selected by memory management to be 
rolled-out, but has TILINE I/O in progress, or 

* The task has issued a Get Memory SVC. 

Since TILINE I/O accesses the task's memory directly, the task 
cannot be immediately rolled-out; therefore memory management 
flags the TSB to indicate that it is being "quieted" (waiting for 
the I/O to complete) . The TSB remains on the active queue untwj 
the I/O is complete, at which time the scheduler queues the t|| 
onto the quieted queue. 
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The TSBs of tasks which issue Get Memory SVCs are immediately 
queued on the quieted queue. 

All tasks that are on the quieted queue are rolled-out by the 
task loader. 

The task loader is a dedicated server of the quieted queue; that 
is, the task loader is automatically bid when an entry is made on 
the quieted queue. The loader may also be scheduled to execute 
when the task scheduler decides to try to roll a task into 
memory, although the loader does not "serve" the waiting on 
memory queue. Figure 1-13 shows how the loader processes the two 
queues. 

When the loader is executed, it first processes all of the 
entries on the quieted queue, rolling them out of memory, 
requeueing the TSBs onto the waiting on memory queue, and 
releasing the now vacant memory used by the tasks. When the 
quieted queue is empty, the loader checks to see if there is a 
task waiting on memory, (a TSB on the waiting on memory queue). 
If not, the loader issues a Suspend Awaiting Queue Input SVC, 
returning control to the scheduler. 

If a task is waiting on memory, the loader checks for attached 
procedures, and tries to allocate memory for them (the allocation 
logic first checks to see if the procedure is already in memory) . 
If memory is found, the loader calls memory management to 
allocate memory for the task segment. If no memory is available, 
the load is left pending, and the loader checks to see if any 
more entries have been made on the quieted queue. At the end of 
the allocation phase, the loader checks to see if all of the 
memory required is still allocated. This might not be trueif 
memory management has rolled out procedure 1 when allocating 
memory for procedure 2. 

If all of the memory is safely allocated, the loader loads the 
task and procedures (unless they were already in memory) from 
either the roll file (for roll-ins) or a program file (for 
initial bids). If the loaded task is flagged as memory resident, 
the loader assumes that it was part of the initial program load 
(system boot) and puts the task in a terminated state. 
Otherwise, the loader queues the task on active queue priority 0, 
slot 2 (head of the queue). This is done, regardless of the 
task's assigned priority, in order to insure that the task will 
get a time slice before it could be rolled-out by a higher 
priority task. 

After the task has been loaded, or some error has interrupted the 
load, the loader once again checks the quieted queue for entries. 
If there are any, the loader starts all over at the top of the 
cycle; otherwise, the loader suspends itself, returning control 
to the scheduler. 
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1.2.3.3 Memory Management. All memory is dynamically allocated 
and deallocated by a collection of nucleus routines called memory 
management, which organizes the available memory into four 
separate groups: 

* Free system table area 

* Allocated system table area 

* Free user memory 

* Allocated user memory 

Free blocks of system table area are all linked on a single list, 
headed by SAHEAD, an anchor contained in the DX10 data base 
module (described in Section 7) . 

The allocated blocks of system table area are the various system 
data structures, such as task status blocks, and are not all 
linked on a single list since the data structures have different 
linking arrangements. 

Requests for system table area are serviced immediately by 
table area allocating routine, MM$GSA. Since nothing in thl 
system table area can be rolled (all system tables and device 
buffers are essential), the request is filied from available area 
only, and must immediately fail or succeed depending on how much 
table area is free. The allocation routine does a first-fit, 
linear search of the free table area list, starting at the list 
header. If the search is unsuccessful, the routine scans the TSB 
list, checking for disk resident queue servers which are 
suspended awaiting queue input. If such a task is found, its 
memory is deallocated, (requiring that the task be rebid when 
needed again,) and the search for table area is restarted. 

Free blocks of user memory are linked on a single list headed by 
UAHEAD, another anchor in the data base module. 

Allocated blocks of user memory, which may contain tasks, 
procedures, or file blocking buffers, are linked together on a 
time-ordered list (TOL) . Whenever one of these blocks is 
accessed, (that is, whenever the task executes, or the blocking 
buffer is read or written to) , that block is removed from its 
current position on the TOL and relinked at the head of the list 
when it is no longer being used. Thus, the list is ordered, the 
first blocks on the list being the most recently used and the 
last blocks being the least recently used. Figure 1-14 shows how 
the time-ordered list is structured. 
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Requests for user memory, such as for tasks and procedures, ars 
not always serviced immediately. * The find memory routine, 
MMSFND, only processes one request at a time; further requests 
are queued until they can be serviced. The find memory routine 
first searches the available memory list, using a first-fit 
search. If a free block of adequate size is found, the starting 
address of the block is returned to the requester. If no free 
block is available, the TOL is scanned (by MM$SCN) for a rollable 
block of memory. 

The TOL scan is from oldest (least recently used) block to newest 
(most recently used) . Blocks are chosen for roll-out according 
to the following rules: 

1. Any buffer except the memory resident buffer; if the 
requester is buffer management, then the memory 
resident buffer may also be chosen. 

2. Tasks with lower priority. 

3. Higher priority tasks that have been suspended longer 
than a time threshold (prevention of thrashing). 

4. Equal priority tasks that have received a minimum 
number of time slices since being loaded into memory. 

5. Any procedure with no currently attached tasks in 
mentor y . 

6. Tasks that have" TILINE I/O in progress may be flagged 
for quieting, and subsequent roll-out, if the memory 
requester is not buffer management. 

7. Queue servers that are suspended awaiting queue input. 

Tasks that may not be rolled-out are: 

1. Tasks that have an alternate task (see Section 6, Data 
Structures for a description of alternate tasks) . 

2. Tasks that are queued for the system overlay loader. 

3. File utility task (FUTIL) when it is accessing a 
directory. 
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If the TOL scan is successful, the block chosen is rolled-out (if 
it is a task or procedure), written to its file (if it is a 
blocking buffer and has been modified) , or simply released (if it 
is a queue server's memory or an unmodified buffer) . The rolled 
block of memory is released from the TOL and put back on the free 
memory list. As blocks are added to the free memory list, they 
are merged with any immediately preceding or following blocks to 
reduce fragmentation. After a successful scan of the TOL, the 
find memory routine again searches the free block list. If a 
large enough block is still not available, the TOL is scanned 
again for another rollable block. Figure 1-15 shows how user 
memory is found. 
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1.2.4 Device I/O Flow 

An executing task performs I/O via an I/O SVC, and is directed to 
a Logical Unit Number (LUNO) . The I/O SVC is decoded by the SVC 
decoder, as described in paragraph 1.2.1, and control passes to 
the I/O supervisor, DXIOS. The I/O supervisor determines from 
the I/O opcode that the call is not for file utility. It then 
searches the logical device table tree for the logical device 
table (LDT) corresponding to the LUNO to which the I/O is being 
directed. 

An LDT is a system data structure that is created for each LUNO 
assigned. The LDT describes the logical unit, whether it is 
assigned to a file or a device (see Section 6, Data Structures, 
for a detailed description of an LDT) . All LDTs in the system 
are linked in a hierarchy according to the type of LUNO which 
they describe (Figure 1-16) . LDTs for task local LUNOs are 
linked on a list of LDTs anchored in the TSB for the task. This 
list is in turn linked to the terminal local LDTs for the 
terminal with which the task is associated (if any), which are in 
turn linked to a single list of LDTs for global LUNOs. 

When the I/O supervisor searches for the LDT of a LUNO, it 
searches for the LDT starting at the anchor in the calling task's 
TSB. The list is searched linearly through the task local LDTs, 
then the terminal local LDTs (if any), and finally the global 
LDTs, until an LDT for the desired LUNO is found. Note that this 
causes task local LUNOs to mask global or terminal- local LUNOs. 

When the I/O supervisor finds the LDT, it determines whether the 
I/O is to a device or file. Device I/O call blocks are buffered 
into the system table area. If there is a data buffer (such as 
for read or" write operations) and the I/O requested is non-TILINE 
I/O, it is also buffered in the system table area. At this 
point, the I/O supervisor checks the physical device table 
(described in Section 6) to see if the device is busy. ^ If not, 
control is immediately passed to the device service routine (DSR) 
for the device. Otherwise, the buffered call block is placed on 
the device queue. If the I/O call is Initiate I/O and the 
calling task has not exceeded a certain threshold number of 
Initiate I/Os, control returns immediately to the calling task. 
If the call is not Initiate I/O, the task is suspended until 
completion of the I/O. 
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When processing an I/O request, the I/O supervisor checks the 
calling task to determine whether it has dynamic priority or not. 
If it does, the priority is updated according to the type of I/O 
being done. 

When the DSR finishes the I/O operation, it calls an end-of- 
record routine (ENDREC) which increments the end of record (EOR) 
counter in the calling task's TSB and places the TSB on the 
active queue. When the scheduler allots a time slice to the 
task, it checks the EOR count in the TSB. If the count is non- 
zero, the task is placed on the active queue, and the device 
driv e routine (known as the DDT) is called. Through DX10 release 
3.4, DDT runs as a task. However, later releases implement DDT 
as a module in the SVCs, schedulers map file mapping scheme. 

When the DDT routine is called, it scans the list of physical 
device tables (PDTs) for a device that has completed data 
transfer and therefore needs end-of-record processing. (See 
paragraph 6.3 for more information on PDTs.) When such a device 
is found, DDT processes the end-of-record; it unbuffers the call 
block and data block (if any) into the calling task's memory 
(causing the task to be rolled-in first, if necessary), and 
activates the task. After processing an EOR for a device, DDT 
checks the device queue for queued I/O requests. If a request 
exists, DDT transfers control to the DSR initial entry point. 
When the DSR finishes, it returns to DDT. When the DSR returns, 
or if the device queue is empty, DDT proceeds to the next PDT on 
the list. 

When DDT has checked all the PDTs, it branches to the scheduler's 
entry point. Figure 1-17 shows a simplified flow of the DX10 
logic involved in processing a device I/O SVC. 
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1.2.5 File Utility Flow 

The initial processing of a file utility SVC (opcode >00, 
subopcodes >90 through >9C) is similar to that for device I/O. 
The SVC is decoded by SVCINT, and control passes to the I/O 
supervisor. The I/O supervisor determines from the "ninety" 
subopcode that the call is for file utility. The I/O supervisor 
preprocesses the file utility call by checking for illegal 
opcodes, buffering the I/O call block, and queueing the buffered 
call block for the file utility task. The calling task is 
suspended with a state of "waiting on task driven SVC processor" 
(state >14) . The file utility task, FUTIL, is a queue server and 
is automatically bid when an entry is placed on its input queue. 

When the file utility task gets CPU time, it dequeues an entry 
from its queue and processes that entry. File utility calls may 
be made in the old librarian or DX10 2.2 "FUR" formats. The file 
utility task converts such calls into DX10 3.0 file utility call 
format and then processes them normally. Normal processing 
(performed in module UC$) involves a table look-up of the correct 
processor for the specified file utility subopcode (range >90 
through >9C) , and the transfer of control to that processor. 
When the processor finishes, it returns control to the AM.e 
utility task. 

FU$ then queues the buffered call block for the SVC cleanup task, 
SVCCLN, which unbuffers the call block into the calling task's 
memory, and reactivates the task. Figure 1-18 shows the flow of 
control for file utility SVCs. 
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1.2.5.1 Assigning and Releasing LUNOs. Since the file utility 
opcodes include Assign LUNO and Release LUNO, file utility is 
responsible for building logical device tables (LDTs) and 
maintaining the LDT links. Whenever a LUNO is assigned, an LDT 
must be built in the system table area, and its pointers defined. 
Figure 1-19 shows the different pointers which may be set in an 
LDT. 

All LDTs in memory are linked in a hierarchy according to the 
type of LUNO they describe, (see the device I/O section) . In 
addition to this, all LDTs have a pointer to the PDT of the 
device to which the LUNO is assigned. LDTs of LUNOs assigned td 
files point to the disk PDT of the volume (drive) that contains 
the file. All LDTs also have a pointer to the TSB of the task 
opening the LUNO. 

LDTs of LUNOs assigned to files also have two .additional 
pointers. All of the LDTs of LUNOs assigned to the same file are 
linked on a common list. Also, each file LDT has a pointer to 
the file control block (FCB) of the file to which the LUNO is 
assigned. 

An FCB is a data structure maintained in the system table area 
which is used to describe a file (see Section 6) . For every file 
that is currently being referenced, that is, having LUNOs 
assigned to it, file utility maintains an FCB tree for all 
pathname components (higher level directories) of the file's 
pathname. 

For example, if a LUNO is assigned to 

VOLUME4.USER0 5. SOURCE. DEBUG, an FCB for USER05, SOURCE, and DEBUG 
will be in memory, linked together. The LDT for the LUNO 
assigned to DEBUG points to the DEBUG FCB, and is also linked on 
the list of LDTs' for the file (see Figure 1-20). Note that the 
FCB for the volume directory (VCATALOG) , an assumed component of 
every pathname, is always in memory when the volume is installed. 
A pathname can have a maximum of 49 bytes, which is 1 byte for 
the length of the pathname and 48 bytes for the pathname itself. 
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When a LUNO is released, file utility searches the FCB/LDT tre* 
for the LDT of the LUNO being released. The LDT is delinked from 
the various lists it is on and released to the free system table 
area list; any blocking buffers associated with the LDT are 
released. If the LDT is linked to an FCB, file management checks 
to see if any more LDTs are linked to the file. If not, the file 
must not be used currently, and the FCB is delinked from the FCB 
tree and released to the system table area. The search continues 
up the FCB tree. As long as an FCB has no LDTs linked to it 
(that is, no LUNOs assigned to the file), and has no descendant 
FCBs (that is, if the FCB represents a directory file that is not 
being accessed and has no cataloged files being accessed), it is 
delinked from the FCB tree, and the release LUNO search continues 
at the parent FCB. 
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Figure 1-19 Logical Device Table Pointers 
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1.2.5.2 Creating and Deleting Files. Creation of a file under 
DX10 involves the following process: 

1. The FCB tree of the directory under which the file is 
to be created is built in memory. For example, if the 
file VOLUMEA.USERO 5. SOURCE. DEBUG is being created, an 
FCB must be in memory for the VCATALOG, USER0 5, and 
SOURCE directories. This structure is necessary in 
order to access the directory VOLUMEA.USERO 5. SOURCE on 
the disk. A pathname can have a maximum of 49 bytes, 
which is 1 byte for the length of the pathname and 48 
bytes for the pathname itself. 

2. File utility searches the disk directory to see if the 
file being created already exists. If so, an error is 
returned; otherwise, processing continues. 

3. A file descriptor record, which is a directory entry 
(see paragraph 4.3.4.2) for the file being created, is 
built in memory, and inserted into the directory on the 
disk. 

Deletion of a file involves a process similar to the one 
described above. The FCB tree must be built in order to access 
the directory in which the file is cataloged (note that the FCB 
tree may already be in memory) . The file descriptor record in 
the directory is released and made available. The FCB 

•representing the deleted file is released if it is currently in 
the system table area. In addition, the path up the FCB tree 
from the deleted file is searched for FCBs with no descendants 
(directories which are no longer being accessed). Any such FCBs 
are delinked from the FCB tree and released to the system table 
area. 

1.2.6 File I/O Flow 

The initial processing of a file I/O SVC is also similar to that 
for device I/O. The I/O supervisor determines from the I/O 
opcode that the call is for file management services. It then 
tests the I/O request to see if a "fast transfer" is possible. A 
request is eligible for "fast transfer" if the following 
conditions are met: 
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* The file is not opened for unblocked I/O 

* The I/O is for a sequential or blocked relative record 
file 

* The operation is a read or write {not forced write) 

* The file is not currently being accessed 

* The record desired is already buffered in memory (that 
is, it has recently been accessed and the buffer has not 
yet been destroyed) . 

If all of the conditions are met, control is transferred to the 
file management read or write routine, the desired I/O is 
performed directly between the file buffer in memory and the 
calling task's data buffer, and control returns to the calling 
task. Thus, the I/O operation is performed by XOP level code, 
and the calling task is not suspended. If the conditions are not 
met, the call block is buffered into the system table area and 
queued for file management. The file management request queue is 
served by a number of replicas of the file management task, 
FM$TSK. This number is specified during system generation. The 
file I/O queuing routine searches a list of file management tasks 
for a suspended task, and activates one if possible. 



FM$TSK is the main driver for file I/O processing. It dequeu 
an entry from the queue, and checks to see if the file is already 
being accessed by another FM$TSK, If so, it queues the request 
on a queue of I/O requests for that file, and dequeues another 
entry from the file management request queue. If not, FM$TSK 
checks the I/O opcode, and tranfers control to the correct 
processor. If the file being used is a key indexed file, control 
transfers to the key indexed file I/O driver, KI$BEG. When the 
processor returns, FM$TSK unbuffers the call block and key 
indexed file currency information, if necessary, into the calling 
task, and reactivates the task. It then checks for more queue 
entries, first on the queue for the same file, and then on the 
file management request queue. If more exist, it processes them. 
When the queue is empty, FM$TSK suspends via SVC >24. Figure 1- 
21 shows a flowchart of the top levei of file I/O processing. 

Some of the subopcode processors, such as FMOPEN for open calls, 
do no more than access the logical device table (LDT) assigned by 
the calling task to the file. The read and write processors work 
in conjunction with buffer management to transfer data between 
the disk file and user buffer. The following paragraphs describe 
the file buffering scheme used by DX10 file management. 
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1.2.6.1 Blocked File I/O. I/O operations to blocked files (any 
type of file except unblocked relative record - see Section 4 for 
a description of file types) are handled through a group of 
routines called buffer management. 

To access a specified logical record of a file, the file ohysical 
record that contains the desired logical record is read "into a 
blocking buffer. These buffers are allocated from user memory, 
and are linked onto the time ordered list when not being used. 
The buffers are linked and delinked, read and written, created 
and released by buffer management routines. 

When file management receives an I/O request for a particular 
logical record of a file, it calls a buffer management routine to 
get the buffer that contains the physical record which in turn 
contains the desired logical record. If the specified physical 
record is already in a buffer on the TOL, the buffer management 
routine simply delinks the correct buffer and maps it into the 
file management task; if not, the buffer management routine 
creates a new buffer, reads the specified physical record from 
the file, and maps it into the file management task. 

The file management processor also calls a buffer management 
routine, BM$MAP, to map the calling task's data buffer into file 
management. Having both buffers mapped in allows file management, 
to avoid using long distance instructions when transferrinq datl 
between the two buffers. " 

After the file management processor has completed transferring 
the specified logical record, it calls another buffer management 
routine to release the file blocking buffer, which is relinked 
onto the head of the TOL. 

DX10 uses blocking buffers to reduce the actual number of disk 
accesses required to perform a given number of file I/O 
operations. Since buffers are not immediately released, but 
rather stay on the TOL until their memory is required by memory 
management, a read or write request to a blocked file record may 
be made to a buffer already in memory, rather than necessitatinq 
a disk access. 

1.2.6.2 Unblocked File I/O. I/O operations to unblocked files, 
such as program, image, directory, and unblocked relative record 
files) do not use intermediate blocking buffers. The file 
management processor calls BM$MAP to map in the calling task's 
data buffer, and then calls the file management disk I/O routine, 
FM$IO, to transfer the record directly between the disk and data 
buffer. 
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1.2.7 Task Termination 

There are four ways for a task to terminate execution: 

* Issue an End Task or End Program SVC 

* Issue a Suspend Awaiting Queue Input SVC (system tasks 
only) 

* Create an error and go into end action 

* Be killed by another task issuing a Kill Task SVC 

All terminated tasks, except tasks which are suspended awaiting 
queue input, have their memory released and their TSBs queued for 
the termination task, TM$DGN. 

TM$DGN performs such general clean-up actions as: 

* Closes LUNOs opened by the terminated task 

* Releases task local LUNOs assigned by the terminated 
task 

* Delinks the TSB from its family tree structure 

* Activates the parent task if specified 

* Sends any error message to the system log 

* Clears any breakpoints for the terminated task 

* Releases the TSB, if the task is not memory resident. 
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The following paragraphs describe what happens to a task sk 
termination. 



1.2.7.1 End Task/End Program SVC. The End Task and End Program 
SVCs are both processed by a routine in the module TM$FUN. This 
routine checks the TSB of the executing task {the task issuing 
the SVC) for any outstanding I/O. If any exists, it is aborted, 
and the task is left on the active queue in order to allow the 
device driver task to process the task's end-of-records. The 
kill flag in the TSB is set, to notify the task scheduler that 
the task has been terminated. 

When a task's kill flag is set, and it has no outstanding I/O, 
either the scheduler or the end task/end program routine queues 
the task's TSB for processing by the termination task, TM$DGN. 
If the task is not memory resident, its memory is released. 

1.2.7.2 Suspend Awaiting Queue Input SVC. This SVC is also 
processed by a routine in the TM$FUN module. This routine simply 
enters a state >24 in the task's TSB, and resets the task's PW 
and WP register values to restart it. The task's memory is not 
immediately released, nor is its TSB queued for the termination 
task. Since the task is not processed by TM$DGN, it should 
release all task local LUNOs before issuing this SVC. 

1.2.7.3 Error Termination. When a task causes an internal error 
interrupt, such as an address out of range or a memory parity 
error, it is forced to go into end action. If the task has no 
end action, or when the end action terminates, the task's memory 
is released and its TSB is queued for the diagnostic task. 

1.2.7.4 Kill Task SVC. When a task is killed, ;it is forced into 
end action, and then queued for the diagnostic task. 
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Section 2 
Organization and Structure of DX10 Source Libraries 



2.1 GENERAL 

This section is a guide to searching a DX10 source disk for a 
particular module. It contains a tabularized description of the 
top level directories and their contents. A disk map of the DX10 
Operating System source disk is contained in the Product 
Documentation Package manual for the DX10 source (part number 
2250958-0001) . 

The DX10 source and object modules are cataloged under a 
directory structure that is generally organized as follows: 

* The level one directories (directories under VCATALOG) 
break the DX10 code into specialized sections such as 
task manager, disk-manager, GEN990, and the key indexed 
file processor) . 

* Each level one directory generally contains two sub- 
directories, OBJECT and SOURCE. 

* The OBJECT and SOURCE directories contain the object 
and source modules of DX10 routines associated with the 
general function implied by the level one directory 
name (for example, task management routines, and memory 
management routines) . 



2.2 TOP LEVEL DIRECTORIES 

Table 2-1 gives the names of the top level source directories 
(cataloged directly under VCATALOG) and a brief description of 
the contents of each one. 
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Directory 
ANALZ 

BATCH 

BDLINK 

CD 

CONDASM 

CVD 

DCOPY 

DEBUGR 

DEVDSR 

DSCBLD 
DSCMGR 

DXIO 

DXLINK 
DXMISC 

DXUTIL 
FILMGR 



Table 2-1 Top Level Directories — Part 1 of 3 

Nam e Contents 

The routines that make up the system crash 
analyzing utility, ANALZ. 

Several SCI batch command streams used to build a 
DXIO system disk. 

Link Editor control streams, link maps, and linked 
object used by the disk build utility. 

These routines make up the Copy Directory utility. 

Constants and variables used for conditional 
assemblies. 

These routines make up the Copy and Verify Disk 
utility. 

These routines make up the Disk Copy utility. 

The routines that make up the debugger. 

The device service routines for all supports 
devices. u 

The routines that make up the disk build utility. 

The disk manager routines; the main driver is 
DM$TSK. 

The DXIO I/O routines, excluding file management 
and file utility. DXIOS is the main driver, that 
is, it processes all code 00 SVCs. 

Link Editor control streams, link maps, and linked 
object of various parts of DXIO. 

Miscellaneous routines and modules within DXIO, 
including: D$DATA, DXDAT2, SVC processors, boot 
loader. 

DXIO 2.X to 3.1 disk conversion utility routines. 

File management routines; the main driver is 
FM$TSK. The routines for handling key indexed 
files and program files are cataloged elsewhere. 
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Table 
Directory Name 
FUTIL 
GEN990 

GENPLINK 

IDS 

KIFILE 

LINKER 

MACROS 

MEMMGR 

NOSHIP 

PATCH 

PGFILE 

RELDOCS 

SCI990 

SCIDX7 
SDSMAC 

SYSTEM 



2-1 Top Level Directories — Part 2 of 3 

Contents 

File utility routines; the main driver is FU$ . 

Routines and data files that make up GEN990, the 
system generation program; the main driver is 
GEN. 

Link Editor control stream, link maps and linked 
object used by GEN990 to generate a system. 

These routines make up the Initialize Disk 
Surface utilities. 

Key index file managing routines and overlays; 
the main driver is KI$BEG. 

Batch streams, control file, and Link Editor 
routines. 

These Macros are used for often performed 
functions including SVC call and OS linkage. 
Macros are included in a module via a COPY 
statement. 

Memory management and buffer management routines. 

Dummy debugger. 

Patch files for sysgen and system program file. 

Program file handling routines. 

Release documentation for major (3.X) and minor 
(3.X.X) DX10 releases. 

Batch streams and control streams to generate 
SCI, and SCI routines. 

SCI modules for the DX7 operating system. 

Batch streams and control streams to generate the 
macro assembler, and the assembler routines. 

Templates of system tables and data structures. 
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Table 
Directory N ame 
SYSTSK 

TEMPLATES 

TI 
TSKMGR 

TXLINK 

UTCOMN 
UTDIRP 

DTDXTX 
UTGENR 

UTLINK 

UTSVC 



2-1 Top Level Directories — Part 3 of 3 

Contents 

Various system tasks, including: MVI , 
install/unload volume (I$VOL, U$VOL) , initialize 
disk (IDSC) , diagnostic task (TMDGN) . 

Symbol equates and offset used by the system and 
utility routines. Templates are included in a 
module via the assembler COPY statement. 

The assembly language test program. 

Task management routines, including: scheduler, 
loader, rolling routines, and so on. 

Link editor control streams, link maps, and 
object for the TX/DX file conversion routines. 

Common routines used by various DX10 utilities. 

Directory utility routines (for example, for copy 
directory, delete directory, backup directory, 
and restore directory) . 

DX/TX file conversion routines. 

General utility routines, including DCOPY, SIS, 
STS, CKS, IDT, MAD, SAD, and so on. 

Link Editor control streams, link maps and object 
for linking most of the utility routines. 

More utility routines, including Map Disk. 
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Section 3 
System Loaders 



3 . 1 GENERAL 

The software for loading and initializing the DX10 operating 
system includes: a program image loader on track 1 of all 
initialized disks, a specialized loader for loading DX10 images 
and initialization of various parts of the operating system, and 
a system restart task which further initializes DX10 and which 
bids any user specified restart task (GEN990 ID parameter) . 

In addition, the ROM bootstrap loader (multiwire - PN 945134- 
0013; printed circuit - PN 945134-0014) which can load a program 
from cards, cassette, magnetic tape, or disk, is used to load the 
program image loader. 

The normal sequence for loading a system image is: 

1. Initiate the boot loader (by pressing the HALT, RESET, 
and then LOAD buttons on the front panel) . This is the 
initial program load (IPL) procedure. 

2. The boot loader loads the disk program image loader, 
starting at location >A0. 

3. The disk program image loader determines where the end 
of its address space (highest address) is, relocates 
itself to the high end of memory, then reads in the 
special system image loader, starting at location >A0. 

4. The system image loader relocates itself to the high 
end of memory, loads the DX10 image specified in the 
disk volume information (track 0, sector 0) , 
initializes system variables, bids the system restart 
task, and transfers control to the operating system. 

5. The system restart task, executing under control of the 
operating system, performs more initialization of the 
operating system and then bids the user specified 
restart task, if one was specified when the loaded 
system was generated. 
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3 . 2 THE BOOT LOADER 

The bootstrap loader which is contained in ROM, is capable of 
loading a program from either cards, cassette, magnetic tape, or 
disk. The loader can be programmed to load from any of these 
media by inserting values in the boot workspace (memory locations 
>80 - >9F) via the front panel of the 990/10 computer. 



Location >80 is used to specify the loading device, according 
the following rules: 

* If the content of >80 is positive, load from the card 
reader at the preferred location (CRU address >40) . 



to 



If the content is zero, load from a 
preferred location (CRU address 00) . 



cassette at the 



* If the content is negative, load from the TILINE device 
(magnetic tape or disk) at the address specified in 
location >82. 

If the loading device is a TILINE device, locations >82 and >8* 
are used to specify the TILINE address and unit select, 
respectively. The unit select value specifies which device on a 
multiple-device controller is to be used. For magnetic tape 
controllers, the following values should be used: 



>8000 


- 


unit 





>4000 


- 


unit 


1 


>2000 


- 


unit 


2 


>1000 


- 


unit 


3 



For disk controllers, the following values should be used: 



>0800 


- 


unit 





>0400 


- 


unit 


1 


>0200 


- 


unit 


2 


>0100 


- 


unit 


3 



The default values, which are inserted into these locations by 
pressing the HALT button on the front panel, cause the ROM loader 
to load from disk unit at TILINE address >F800. Note that when 
loading from a disk, the ROM loader always loads the program 
image loader from track 1; however, when loading from cards, 
cassette, or magnetic tape, it loads whatever program image is 
read from the device. 
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3.3 THE DISK PROGRAM IMAGE LOADER 

The loader SYSLD, which resides on track 1 of every DX10 3.0 
formatted disk, is capable of loading any standalone program from 
an image file on disk into memory. After the program is loaded 
by the boot loader at location >A0, it relocates itself to the 
high end of its address space, (that is, the high end of 32K 
words) . It then determines what program to load by using the 
volume information in sector of track on the system disk (see 
paragraph 4.2.1 for a description of the volume information). 

The program to be loaded is chosen according to the following 
rules: 

1. If the diagnostic flag in the volume information is Y, 
(that is, non zero) , the diagnostic task, which can be 
any standalone task, will be loaded, and the flag reset 
to N (zero) . 

2. If no diagnostic is specified, the loader checks to see 
if the file pathname of either a primary or a secondary 
system loader is specified. If so, the image loader 
loads whichever system loader is indicated by the flag 
(0=load primary, l=load secondary, -l=load secondary 
and reset flag to zero) . 

3. If no system loader is specified, the image loader 
loads the system image indicated by the image flag, 
which is used in the same manner as the system loader 
flag. 

The program image loader normally loads a program image starting 
at memory location >A0. This default load bias is stored in the 
second word of the loader, and may easily be changed by a Modify 
Absolute Disk (MAD) command. Note that, since the image loader 
neither changes memory mapping nor uses long distance 
instructions, it always loads in its own address space. When the 
loader is booted by the ROM loader, it is always mapped into the 
first 32K words of memory. 
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3.4 THE SYSTEM LOADER/INITIALIZER 

The DX10 system loader, module STARTR, is normally located on 
file .S$LOADER. This program assumes it has been loaded starting 
at location >A0 by the program image loader, and relocates itself 
to the high-order 8K bytes of physical memory. It then 
determines the name of the operating system to be loaded from the 
program file .S$IMAGES, by reading the volume information on 
track 0, sector 0. The system select flag indicates which system 
image is to be loaded (0=primary, l=secondary, -l=load secondary 
and reset flag to zero) . 

After obtaining the name of the system to be loaded, the system 
loader verifies that the system files in .VCATALOG are correct 
for the version of DX10 being used, and then loads the system 
from .S$IMAGES, starting at location >A0 . 

After loading the system image, STARTR performs the following 
initialization functions: 

* Initializes the map files for all of the system 
segments. 

* Renames the disk drives (if necessary) to make the 
system disk DS01. 

* Initializes memory beyond the end of the loaded system 
to a constant pattern (>B00B) . 

* Initializes memory size parameters. 

* Initializes the interrupt and XOP trap vectors in memory 
locations >00 - >80. 

* Creates file control blocks and logical device tables 
for VCATALOG, the system program file, the system 
overlay file, and the roll file. 

* Enters the power up code of each device service routine 
in the system. 

* Loads memory resident procedures and bids memory 
resident tasks. 

* Initializes free memory pointers. 

* Bids the system restart task, SYSRST. 

After initialization, the system loader releases control to the 
task scheduler . 
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3.5 THE SYSTEM RESTART TASK 

When the operating system starts up, the first task scheduled for 
execution is the system restart task, SYSRST. This task performs 
initialization functions that are easier to do under a running 
operating system than in the system loader. SYSRST verifies that 
the .S$LOADER was for the correct version of DX10 and also bids 
the user specified restart task if there is one (the user restart 
task must be on the system program file, and is specified during 
system generation) . 

The initialization functions performed by SYSRST are: 

* Delete all temporary files on the system disk 

* Assign global LUNO >10 to the language program file, 
S$SDS 

* Assign global LUNO 1 to the foreground TCA file, S$FGTCA 

* Assign global LUNO 2 to the background TCA file, SSBGTCA 

* Assign global LUNO 3 to the master TCA library file, 
S$TCALIB 

* Enables the SCI bidding logic within the operating 
system 

* Bids the system log command processor to start file 
logging . 
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Section 4 
Disk Organization and Data Structure 



4.1 DISK FORMAT 

Under DX10 , all tracks on disks are initialized in one sector per 
record format. Note that this record is a disk characteristic 
and is not the same as the physical record size specified when 
creating files. 



DX10 disks are logically divided in 
(ADUs) , as described in the DX10 
Programming Guide . An ADU is defined 
sectors on the disk, the number of 
according to disk size (see Table 4- 
be less than 65,536, (each ADU on the 
bit word) , and the sectors per ADU is 
are numbered from zero, with the fi 
sector 0. 



to allocatable disk units 

Operating System Systems 

to be an integral number of 

sectors per ADU varying 

1) . The number of ADUs must 

disk addressable by a 16- 

1 or a multiple of 3. ADUs 

rst ADU starting on track 0, 



Table 4-1 


Format Information for 


Supported 


Disks 




No. of 


No. of 


Sectors/ 


Bytes/ 


Disk Type 


Sectors 


ADUs 


ADU 


ADU 


DS10 


16320 


16320 


1 


288 


DS25 


77520 


25840 


3 


864 


DS31/DS32 


9744 


9744 


1 


288 


DS50 


154850 


51616 


3 


864 


DS80 


244915 


40819 


6 


1536 


DS200 


588430 


65381 


9 


2592 


DS300 


930677 


62045 


15 


3840 


CD1400/32 










Removable 


52544 


52544 


1 


256 


Fixed 


52544 


52544 


1 


256 


CD1400/96 










Removable 


52544 


52544 


1 


256 


Fixed 


262716 


43786 


6 


1536 


WD500/5 


19200 


19200 


1 


256 


WD800/18 


72261 


24087 


3 


768 


WD800/43 


168609 


56203 


3 


768 
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4.2 PHYSICAL ORGANIZATION OF THE DISK 

To prepare the disk for use, surface analysis and initialization 
of the disk must be performed. Surface analysis is performed by 
using the IDS (Initialize Disk Surface) command. After execution 
of this command, the disk state word in track zero, sector zero 
contains a value of two. Additionally, bad tracks (physical 
imperfections) on the disk are indicated. Each bad track is 
indicated in pairs of words. The first word indicates the first 
of any contiguous group of bad tracks, and the second word 
indicates the number of contiguous tracks. Initialization of a 
disk is performed by using the INV (Initialize New Volume) 
command. When a disk is initialized, the disk state word in 
track zero, sector zero contains a value of three, indicating 
that the disk is now ready for use. Bad disk areas are indicated 
by ADUs in pairs of words. The first word contains the ADU 
address of the first of any contiguous group of bad ADUs. The 
second word contains the address of the last ADU in the group. 

All disks that have been initialized under DX10 have the 
following physical layout: 

* Track 0, sector — contains information about the disk 
volume, such as the volume name and pointers, to the 
volume directory (VCATALOG) . 

* Track 0, sector 1 — contains a list of bad (in the 
sense of physical imperfections) areas on the disk. 
Each entry is two words: the first word is the address 
of the first bad ADU; the second word is the address of 
the last bad ADU. A zero word terminates the list. 

* Track 0, sector 2+ — the remainder of track contains 
disk allocation information, in the form of bit maps. 

* Track 1, sector 0+ — is reserved for the disk program 
image loader described in Section 2. 

* Track 1, penultimate sector — a copy of track 0, sector 

u • 



* 



* 



Track 1, last sector — a copy of track 0, sector 1. 
The remaining tracks are available for file allocation. 
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The following paragraphs describe the track information in 
greater detail. 

4.2.1 Volume Information 

The information contained in track 0, sector of all disks 
intialized under DX10 is called volume information. Figure 4-1 
shows the format of the 14 0-byte block of information. 

The following is a list of the volume information contained in 
track 0, sector 0. Note that some fields have zero values when 
the disk is initialized. 



Hex. 



Byte 
>00 



>1C 



RESERVED 



>08 


l- — 


BIT 


MAP 


NUMBER OF ADUs 






>0A 


START SECTOR j 


NUMBER OF 


BIT 


MAPS 


>0C | 






TRACK RECORD 


LENGTH 






>0E | 






PROGRAM IMAGE LOADER TRACK 






>10 








RESERVED 








>16 


1 






NUMBER OF BAD 


ADUs 






>18 


1 






PROGRAM IMAGE LOADER 


ENTRY POINT 




>1A 








PROGRAM IMAGE LOADER LENGTH 







+ + 

Figure 4-1 Volume Information Format (VIF) — Part 1 of 3 
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Hex. 
Byte * 

+ 

>24 | PROGRAM IMAGE LOADER TRACK 



+- 
>26 I 



+- 
>2E I 



+- 



+- 



>4A 



+- 
>52 I 



>5C 



RESERVED 



PRIMARY SYSTEM IMAGE FILE NAME 



SECONDARY SYSTEM IMAGE FILE NAME 



+ , 

>3E | SYSTEM IMAGE SELECT FLAG 

+ 

>40 | VCATALOG STARTING ADU 

+ 

>42 | VCATALOG PHYSICAL RECORD SIZE 



>44 j SECTORS /ADU 

+ 

>46 I CREATION DATE 



PRIMARY PROGRAM FILE NAME 



SECONDARY PROGRAM FILE NAME 



+ 

>5A | PROGRAM FILE SELECT FLAG 



PRIMARY OVERLAY FILE NAME 



■+ 



>36 | I 



i 



Figure 4-1 Volume Information Format (VIF) — Part 2 of 3 
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Hex. 

Byte 

+ + 

>64 | | 

SECONDARY OVERLAY PILE NAME 



+ + 

>6C | OVERLAY FILE SELECT FLAG | 

+ + 

>6E I I 

PRIMARY SYSTEM LOADER FILE NAME 



+ + 

>76 | I 

SECONDARY SYSTEM LOADER FILE NAME 



+ + 

>7E | SYSTEM LOADER SELECT FLAG | 

+ + 

>80 | | 

DIAGNOSTIC FILE NAME 



+ + 

>88 | DIAGNOSTIC SELECT FLAG 1 

+ + 

>8A | DEFAULT PHYSICAL RECORD SIZE | 

+ + 

>8C | BAD ADU LIST STARTING SECTOR | 

+ + 

>8E | TRACK SECTORS/RECORD | 

+ +. 

>90 | I 

WCS PRIMARY FILE 



+ , + 

>98 | 1 

WCS SECONDARY FILE 



+ + 

>A0 | WCS SELECT FLAG | 

+ + 

>A2 | VOLUME. INFORMATION COPIED FLAG | 

+ — . + 

>A4 j DISK STATE | 

+_- + 



Figure 4-1 Volume Information Format (VIF) — Part 3 of 3 
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Hex. 

Byte Descriptio n 

>00 A 1-8 character volume name, blank filled to the right. 

>08 Total number of allocable disk units contained in the 
volume. This field varies by disk type. 

>0A The number of the sector on track in which the first 
bit map resides. 

>0B Total number of bit maps. 

>0C The number of bytes per physical record, (that is, 
sector) on track 0. This value is also disk dependent. 

>0E The number of the track that contains the disk program 
image loader. This field is initialized to one. 

>10 Reserved. 

>16 Total number of bad ADUs on the disk. 

>18 Entry point address of the disk program image loader 
(initialized to >A6, the entry point of the program code 
when it is loaded at location >A0) . 

>1A Total length, in bytes, of the disk program image 
loader. 

>1C Reserved. 

>24 Second copy of the number of the track that contains the 

disk program image loader (initialized to one) . 

>26 Reserved. 

>2E The 1-8 character name of the primary system image file. 

Zero at initialization. 

>36 Name of the secondary system image file. Zero at 

initialization. 

>3E System select flag. Zero at initialization. 

>40 Number of the ADU in which the volume directory 

(VCATALOG) begins. 

>42 Physical record size of the VCATALOG directory file 

(initialized to >86 bytes) . 

>44 Number of sectors per ADU (disk dependent) . 
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Hex. 

Byte Description 

>46 Disk creation date. 

>4A Primary system program file name. 

>52 Secondary system program file name. 

>5A System program file select flag. 

>5C Primary system overlay file name. 

>64 Secondary system overlay file name. 

>6C System overlay file select flag. 

>6E Primary system loader file name. 

>76 Secondary system loader file name. 

>7E System loader select file. 

>80 Diagnostic file name. 

>88 Diagnostic select flag. 

>8A Default physical record size for the disk (reserved) . . 

>8C Sector in track in which the load ADU list begins 
(equals 1 for DX10 disks) . 

>8E Number of sectors per record on track (always 1 for 
DX10 disks) . 

>90 Primary writable control storage (WCS) file name. 

>98 Secondary writable control storage (WCS) file name. 

>A0 Writable control storage select flag. 

>A2 Volume information copied flag. 

>A4 * 
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4.2.2 Allocation Bit Map 

To keep track of which areas on the disk are allocated and which 
areas are free, the DX10 disk manager maintains a bit map of 
allocated ADUs. The bit map is located on track of each disk, 
starting at sector 2 and continuing through as many sectors as 
necessary. 

The bit map is divided into 128-word partial bit maps. Each 
partial bit map is located in a separate sector on track 0. The 
first word of each partial bit map contains the number of the ADU 
that begins the largest block of free disk space located in that 
part of the disk that is mapped by the partial bit map. Each bit 
in the remaining 127 words represents an ADU. If the bit is 
zero, the ADU is free; a one bit indicates that the ADU is 
allocated (or bad) . 

Figure 4-2 shows a partial bit map. Note that, since each 
partial bit map contains 127 16-bit words of information, it maps 
2032 ADUs. 
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BYTE o 



RELATIVE ADU NO. OF LARGEST 
AVAILABLE BLOCK 



PARTIAL ALLOCATION BIT MAP 

BIT = 1 MEANS 
UNIT ALLOCATED 



2278128 



Figure 4-2 Partial Bit Map 
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4.3 FILE STRUCTURES 

DX10 supports three file types: 
unblocked), sequential files, 
types are based on the unblocked 
system overhead needed 
files. In addition, 
relative record file: 
files. 



relative record files (block and 
and key indexed files. All file 
relative record type, with extra 

to implement sequential and key indexed 
there are three special usages of the 

program files, directory files, and image 



In the following discussion of file types and 
physical record of a file is the amount 



transferred by the operating 
the file; a logical record of a 
the user desires to transfer in 
the physical record size to the 
blocking factor. 



file structures, a 
of data actually 



system during an I/O operation to 
file is the amount of information 
an I/O operation. The ratio of 
logical record size is called the 



4.3.1 Relative Record Files 

A relative record file is a file in which all logical records arjr 
a fixed length and each record can be randomly accessed by itm 
unique record number. Relative record files may be unblocked 
(logical record size equal to physical record size) or blocked 
(logical record size less than physical record size). 

4.3.1.1 Unblocked Relative Record Files. Each logical record of 
a file of this type occupies one physical record of the file. A 
physical record may be any integral multiple of contiguous 
sectors. File accesses require reading or writing this many 
sectors (reads and writes of multiple contiguous sectors can be 
accomplished via one disk access) . Records read from unblocked 
relative record files are transferred directly from the disk to 
the user buffer, without intermediate system buffering. When you 
specify a particular record of the file, the record number is 
converted by file management to an absolute allocatable disk unit 
number and a sector offset within the ADU. The absolute disk 
address is then passed to the disk device service routine (DSR) 
to perform the actual data transfer. The disk DSR converts the 
ADU and relative sector to a physical track and sector disk 
address to communicate with the disk controller hardware. 
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Long Unblocked Relative Record 
Record Size > ADU Size 



LONG UNBLOCKED RELATIVE RECORD , RECORD SIZE > ADU SIZE 



/ 








RECORD 
A 






V 








f \ 




/ 

\ 








ALL DATA 


ALL DATA 


ALL DATA 




I I 


\ 












UNUSED 




V 
ADU 


V 

ADU 




' 


2278129 


V 
ADU 





Unblocked Relative Record 
Record Size < ADU Size 



PHYSICAL 
A 


/ \ 
LOGICAL 

/ A v 


ALL DATA 





UNBLOCKED RELATIVE RECORD 
RECORD SIZE<ADU SIZE 



ALL DATA 


^ 



ALL DATA 



^ m 



RECORD 1 



RECORD 2 



RECORD 3 



2278130 



"V" 

ADU 



UNUSED 
f 



Note that each physical record must begin on a sector boundary 
and that a physical record that starts in the middle of an ADU 
may not span the ADU boundary. 

4.3.1.2 Blocked Relative Record File. These files are the same 
as unblocked except that multiple logical records may be stored 
in each physical record. Logical records may not span physical 
records. Records are transferred via intermediate blocking 
buffers which are furnished from the general pool of user space 
by buffer management. 
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3locked Relative Record File 



BLOCKED RELATIVE RECORD FILE 



PHYSICAL RECORD 1 



PHYSICAL RECORD 2 



REC 1 


REC 2 


REC 3 


REC 4 


V? 




REC 5 


REC 6 


REC 7 


REC 8 


Vt 


\ 


4 LOGICAL RECORDS UNUSED 






4 LOGICAL RECORDS UNUSED 

/ 


2278131 










ADU 













4.3.2 Sequential Files 

Sequential files are blocked relative record files with variable 
length logical records. Logical records may span physical record 
boundaries regardless of ADU boundaries. When a logical record 
spans a physical record boundary, it is broken into partial 
records which are contained in separate blocks. The first word 
of each physical record has two flags indicating whether the 
first logical record is continued from the preceding physical 
record and whether the last logical record is contained in the 
following physical record. Set flag bits (bit = 1) have the 
following meaning: 

Bit Meaning When Set 

First logical record in this physical record is 
continued from the preceding record. 



Last logical record in this 
continues in the next record. 



physical record 



Each logical record or partial record is preceded by a header 
word and followed by a trailer word. The content of the header 
and trailer is the number of bytes of user data between them. An 
end-of-file is signified by a zero length record (zero header and 
trailer) . 

A special condition exists when a record or last partial record 
ends with only one or two words remaining in the physical block. 
Since there is not room for another partial record 
(header/data/trailer), next record will begin in the 
following block. The last word of the current block contains the 
number in the last trailer plus the number of unused bytes (two 
or four) . Figure 4-3 shows how a sequential file is arranged. 
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Logical records of a sequential file may be blank-suppressed, 
that is, the sequential file is created blank-suppressed. In 
blank-suppressed files, all double blanks are removed. A blank- 
suppressed logical record has the following format: 

1. Header word 

2. Byte containing a count of words with double blanks* 

3. Byte containing a count of words with no double blanks* 

4. Data characters* 

5. Trailer word 

* Items 2 through 4 above are repeated as necessary. 
Figure 4-4 shows a blank-suppressed record. 
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BYTE 
O 

2 
4 
6 
8 

A 

C 



PHYSICAL RECORD 



10 
12 
1 4 
1 6 
18 
1 A 
1C 



IE 
20 
22 
24 
26 
28 
2A 



LOGICAL RECORD DATA 



LOCICAL RECORD 1 DATA 



LOGICAL RECORD 2 DATA 



FLAGS 

RECORD HEADER 



RECORD TRAILER 



RECORD 1 HEADER 



RECORD 1 TRAILER 

RECORD 2 HEADER (PARTIAL) 



RECORD 2 TRAILER (PARTIAL) 



PHYSICAL RECORD 1 



LOGICAL RECORD 2 DATA 



LOGICAL RECORD 3 DATA 



LOGICAL RECORD 4 DATA 



FLAGS 

RECORD 2 HEADER (PARTIAL) 



RECORD 2 TRAILER (PARTIAL) 
RECORD 3 HEADER 



RECORD 3 TRAILER 
RECORD 4 HEADER 



} 



RECORD 4 TRAILER 



2 THIS WORD POINTS BACK TO EOF HEADER 

NEXT RECORD STARTS IN NEXT BLOCK 



2278132 



Figure 4-3 Sequential File Format 
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4* 



RECORD HEADER 



RECORD DATA 



RECORD TRAILER 



t 



PHYSICAL RECORD 



THIS IS A B. S. RECORD 



^ 



WORDS OF BLANKS, 1 WORD OF DATA 



2 WORDS OF BLANKS, B, 6 WOROS OF DATA 



1A WORDS OF BLANKS, WORDS OF DATA 



t 



THIS RECORD REPRESENTS THE 80-CHARACTER RECORD BELOW 



* TH'.SiSAB.S. RECORD 



<52 BLANKS > 



2278133 



Figure 4-4 Blank-Suppressed Record 
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4.3.3 Key Indexed Files 

Key indexed files have variable length logical records that can 
be accessed either randomly, by any one of up to 14 alphanumeric 
keys, or sequentially, in the sort order of any key. On the 
disk, a key indexed file with n keys is arranged as follows: 



* 



* 



The first 18n+3 physical records are the KIF log blocks. 
Before modifying any record within the file, it is 
written into a log block, to prevent data loss in case 
ofan error during the data transfer, such as in a power 
failure. In the event of such an error, the logged 
image is written back into the original file record, 
when the file is next opened, and the file operation mav 
be retried. 

The next n physical records are the roots of the 
balanced trees (3-trees) that are used to locate each 
logical record within the file by key. There is a B- 
tree for every defined key (up to 14 B-trees) ; 
therefore, there are n B-tree roots. 

Following the B-tree root nodes • are physical records 
that contain data as well as physical records that 
contain other B-tree nodes. 

The following paragraphs describe the structure of B-trees and 
data records in detail. 

4.3.3.1 B-Trees. B-trees are made up of a root node, branch 
nodes, and leaf nodes. Root nodes are just the first node of the 
tree. Leaf nodes are the nodes that contain pointers to the data 
records. Branch nodes are all the nodes between the root and 
leaf nodes. 

A B-tree, under DX10 , is a multi-wav (having multiple branches 
per node) , balanced tree; that is, all leaf nodes are at the same 
level. DX10 B-trees may not exceed nine levels. Figure 4-5 
shows a sample B-tree, in which the key values are single 
letters. 

Each node of a B-tree occupies one physical record of a key 

indexed file, and is called a B-tree block. Each B-tree block 

contains a few words of overhead and several pointer/key value 
pairs. Figure 4-6 shows a B-tree block. 
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Hex. 
Byte 

>00 

>04 
>06 
>08 

>0C 

>10 
>12 
>14 

>18 

>1A 



BLOCK NUMBER 






| COMMAND NUMBER 




1 


| SPACE REMAINING 




1 


1 PREDECESSOR POINTER 
f OR FREE CHAIN LINK 






SUCCESSOR POINTER 






| NUMBER OF ENTRIES | FLAGS 


1 


[SEQUENTIAL INSERT POSITION | SEQUENTIAL 


INSERT 


COUNTER | 


BLOCK NUMBER 




| 1 
|POI 


I INDEX (LEAF LEVEL ONLY) 




1 



KEY VALUE 



Hex. 
Byte 

>00 



>04 



Figure 4-6 B-Tree Block 



Description 



Physical record number of this B-tree block. This field 
is maintained so that, should a system crash occur while 
this file block is being modified, the logged image can 
be restored to the correct file record. 



The opcode of the file operation being performed, 
field is also maintained for logging purposes. 



This 
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Hex. 

Byte Description 

>06 The number of available bytes remaining to be used in 

this B-tree block. 

>08 If this block is currently being used as a B-tree node, 

this field points to the preceding node on the same 
level (zero if this is leftmost node) . The address is a 
physical record number. If this block is available for 
use, this field points to the next available block (free 
blocks are kept on a linked list) . 

>0C If this block is a B-tree node, this field points to the 

following node on the same level; otherwise, this field 
is unused. 

>10 The number of pointer/key value pairs currently 

contained in this block. 

>11 Flags. Bit 7 is set (byte 17 = 1) if this B-tree block 

is a leaf. 

>12 This byte is zero when the block is initialized due to a 

B-tree split. When the first entry is made to the 
block, this byte contains the number of entries in the 
block that are greater than the new entry. (This 
applies to sequential placement only; otherwise, byte 
>14 is moved up here) . 

>13 When the block is initialized due to a B-tree split, 

this value is the maximum entries that may be inserted 
in the block plus one. For each subsequent entry to 
this block, if the number of entries in the block that 
are greater than the new entry equals the number in byte 
>12, byte >13 is decremented by one. When this B-tree 
block is about to split, if byte >13 is zero, the lower 
90% of the entries are in one block and the upper 10% in 
the other. Otherwise, the split is 50-50. (This 
applies to sequential placement only; otherwise, byte 
>15 is moved up here.) 

>14 These six bytes are the first pointer. If this is a 

non-leaf node, the first four bytes contain the record 
number of a branch or leaf node and the last two bytes 
are meaningless. If this is a leaf node, the first four 
bytes contain a record number of a data record and the 
last two bytes contain the key ID of the logical record 
within the data record. 

>1A The key value of the first pointer/key value pair. 
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The remainder of the B-tree block contains more pointer/key valul 
pairs. These entries in a B-tree block aire kept sorted in 
increasing order of key value {smallest kev value is first 
entry) . 

If the block is not a leaf entry, each pointer field points to a 
subtree that contains all key values less than or equal to the 
key value associated with the pointer. In fact, the highest key 
value contained in the subtree is the key value associated with 
the pointer (as shown in the sample B-tree) . 

Further information on general B-tree structure is available in 
The Art of Computer P rogramming, Volume III by Donald Knuth. 

4.3.3.2 Data Blocks. All of the data records (logical records) 
of a key indexed file are contained in data blocks. A data block 
is a physical record of the file and contains a few words of 
overhead and several logical records, as shown in Figure 4-7. 
The word following the last logical record has a zero value. 
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Hex. 
Byte 

>00 



>0C 



>0E 



>10 



>12 



>04 I 
+- 

>06 | 
+- 

>08 ! 



+- 

I 

+- 



BLOCK NUMBER 



COMMAND NUMBER 



SPACE REMAINING 



OVERFLOW BLOCK OR 
FREE CHAIN POINTER 



HIGHEST KEY ID USED 
RECORD SIZE (1ST RECORD) 



KEY ID 



RECORD 



RECORD SIZE (2ND RECORD) 
KEY ID 



RECORD 



Figure 4-7 Data Block 
Note 1 — Four s overhead bytes per logical record 



■+ — + 

| SEE 
-+ NOTE 



-+ 

! 

-+ 

I 
-+ 
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Hex. 



Byte Descripti on 

>00 Physical record number of this block. This field is 
maintained so that, should a system crash occur while 
this block is being modified, the logged image can be 
restored to the correct file record. 

>04 The opcode of the current command. This field is also 
maintained for logging purposes. 

>06 The number of bytes remaining in the physical record. 

>08 This block is used to link the block on the free block 
chain. 

>0C The highest ID assigned to any logical record with the 
block. 

>0E Size, in bytes, of the first logical record including 
this word. 

>10 The ID assigned to the first logical record. 

>12 First logical record. 

Whenever a data record is to be inserted in a data block, it is 
assiqned an ID that is unique within the block. The data record 
is then inserted in the first available place in the block. 

4.3.4 Special Relative Record Files 

In addition to the three basic file types, three special uses of 
the relative record file warrant description: program files, 
directory files, and image files. 

4.3.4.1 Program Files. Program files are unblocked relative 
record files having a logical record size of one sector. The 
smallest sector size allowed is 256 bytes. Figure 4-8 shows the 
format of a program file. The sections of information describing 
the contents of the program file (see Figure 4-8) will not always 
start at the beginning of records or be in the same place for all 
program files. The following set of equations define the record 
number and the offset into the record of the beginning of the 
sections of information. In the equations, R designates a record 
and designates the offset. 
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Rl = 1 

01 = 

((MAX # TASKS +2)/2) * >10) + 01 

R2 = Rl + — 

>100 

( (MAX # TASKS +2) /2) * >10 + 01 

02 = remainder of — 

>100 



(MAX # TASKS +1) * >10 + 02 

R3 = R2 + 

>100 

(MAX # TASKS +1) * >10 + 02 

03 = remainder of — 

>100 

( (MAX # PROCS +2) /2) * >10 + 03 

R4 * R3 + 

>100 

((MAX # PROCS +2)/2) * >10 + 03 

04 = remainder of 

>100 

(MAX # PROCS +1) * >10 +04 

R5 = R4 + 

>100 

f (MAX # PROCS +1) * >10 + 04 

05 = remainder of 

>100 

((MAX # OVLYS +2)/2) * >10 + 05 

R6 = R5 + 

>100 

( (MAX # OVLYS +2) /2) * >10 + 05 

06 = remainder of 

>100 
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(MAX # OVLYS +1) * >10 + 06 
R7 = R6 + 

>100 

(MAX # OVLYS +1) * >10 +06 

07 = remainder of — , 

>100 

( (MAX # HOLES * 4) +2) + 07 
R8 = R7 + 

>100 

((MAX # HOLES * 4) +2) + 07 

08 = remainder of 

>100 

If 08 is not equal to zero, then R8 = R8 + 1 

R1,01: Record number and offset for names of tasks. 

R2,02: Record number and offset for task directory entries. 

R3,03: Record number and offset for names of procedures. 

R4,04: Record number and offset for procedures directory entries 

R5,05: Record number and offset for names of overlays.- 

R6,06: Record number and offset for overlay directory entries 

R7,07: Record number and offset for unused space directory. 

R8: Record number of first image record. 

The first record (record number 0) of a program file contains six 
bit maps. These bit maps, in order of occurrence within record 
0, are for memory resident tasks, memory resident procedures, all 
tasks, all procedures, all non-replicatable tasks, and all 
overlays. 
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* * 

| OVERHEAD RECORD | 
+ + 

1 1 NAMES FOR TASKS | 
+ ; + 

R2:02 | DIRECTORY ENTRIES FOR TASKS | 

+ + 

R3:03 i NAMES FOR PROCEDURES \ 

+ + 

R4:04 | DIRECTORY ENTRIES FOR PROCEDURES | 

+ , + 

R5:05 j NAMES FOR OVERLAYS | 

+ + 

R6:06 | DIRECTORY ENTRIES FOR OVERLAYS j 

+ . + 

R7:07 | AVAILABLE SPACE LIST | 

+ + 

R8 | IMAGE FORMATS FOR TASKS, PROCEDURES & OVERLAYS I 

* * 



Figure 4-8 Program File Format 

When record zero is initialized, all the bits in the bit map are 
zero except the first bit in the tasks, procedures, overlays, and 
non-replicatable tasks bit maps (the bit maps occupying bytes 
>54->D3) . The first bit of these is a one, restricting user 
tasks from allocating ID zero. 

Each bit map is 16 words by 16 bits per word, and thus is able to 
represent 256 IDs. A bit set to one indicates that the ID 
corresponding to the bit position (0 through 255) is assigned to 
atask, procedure, or overlay segment ; that is installed in the 
file. Figure 4-9 shows the format of record zero of a program 
file. 
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Hex. 

Byte 

* , ,_ * 

>oo | oooo I 

+ . . . ,+ 

>02 | | 

RESERVED (=0) 



+ + 

>10 | I 

RESERVED (=0) 



+ + 

>14 1 | 

BIT MAP FOR MEMORY 
RESIDENT TASKS 

I I 

+ + 

>34 | | 

BIT MAP FOR MEMORY 
RESIDENT PROCEDURES 



+ + 

BIT MAP FOR ALL TASKS ^ 



+ + 

>74 j | 

BIT MAP FOR ALL PROCEDURES 



+ + 

>94 | | 

BIT MAP FOR ALL NON-REPLICATABLE TASKS 



+ + 

>B4 ] | 

BIT MAP FOR ALL OVERLAYS 



+ + + 

>D4 | MAXIMUM NO. OF TASKS | 02 | 

+ + + 

Figure 4-9 Program File Record Zero — Part 1 of 2 
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Hex. 



Byte 

+ + + 

>D6 | R2 | 

+ f + 

>D8 | MAXIMUM NO. OF PROCEDURES | 04 | 

+ + + 

>DA | R4 | 

+ + + 

>DC | MAXIMUM NO. OF OVERLAYS | 06 j 

+ + + 

>DE | R6 i 

+ ■ + 

>E0 | MAX. NO. OF BDLES (TASKS, PROCEDURES, AND OVERLAYS) | 
+ + 

>E2 | 07 | 

+ + 

>E4 | R7 1 

+ + 

>E6 | | 

UNUSED (=0) 



Figure 4-9 Program File Record Zero — Part 2 of 2 

At program file creation time, the maximum number of tasks, 
procedures, and overlays contained in bytes >D4, >D8 and >DC of 
record are defined by the creator of the program file. The 
maximum number of holes, which equals the sum of the above three 
values, is used to calculate the number of bytes required in the 
overhead records for the available space list. This list is 
headed by a word that contains the number of entries in the list. 
The rest of the list consists of 2-word entries that describe the 
unallocated spaces (holes) in the image portion of the program 
file. Each entry contains the starting record number and the 
number of available records in each unused portion of the program 
file. These spaces appear when an image is deleted. This space 
is recorded to be used again if a new image is installed in the 
program file that is the same size or smaller than the one that 
was deleted. Adjacent images, when deleted, create only one 
hole. Figure 4-10 shows the format of the available space list. 

The available space list uses the entire record, not 25 6 bytes of 
it as the other overhead records do. Therefore, if the list 
spans records, an entry is split across two records. (The first 
word of the entry is the last word of one record and the second 
word of the entry is the first word of the next record) . The 
available space list is initialized at the same time record is 
initialized. Its values are as follows: 
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* * 

I 1 | FIRST WORD 

+ + 

I R8 | SECOND WORD 

+ + 

| FFFF-R8 | THIRD WORD 

* — . * 

R8 is the first record following the available space list. 

* , , * 

| NUMBER OF ENTRIES | 

+ + __ + 

! SECTOR NUMBER j | 

I SECTORS AVAILABLE | | 

+ . . _ + __ + 

i * i 

■ 

I I 

+ + __ + 

| SECTOR NUMBER | | 

+ + entry q 

I SECTORS AVAILABLE I I 

* _ *__ + 

Figure 4-10 Program File Available Space List 

The maximum number of records permitted in a program is FFFF. 
Thus, the maximum number of image records permitted in a program 
file is FFFF minus the number of overhead records. The actual 
image of a task, procedure, or overlay must start on a record 
boundary in the program file. If the segment has a relocation 
bit map, it begins at the first word following the program 
segment image. 

The task, procedure, and overlay name blocks in the program file 
contain the names of all tasks, procedures, and overlays 
installed in the program file. A name is eight bytes long, 
blank-filled to the right. The names are placed in the position 
in the name block that corresponds to the ID assigned to that 
segment. For example, if task GENTX is assigned ID 1, the name 
GENTX is entered in bytes 8-15 (second position) of the task name 
block . 
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The task, procedure, and overlay directory blocks in the program 
file contain information about all segments installed in the 
program file, as well as pointers to the segment images. Each 
directory is 16 bytes long. The figures that follow show the 
formats of the program file directory entries, with the field 
description following their respective formats. Figure 4-11 
shows the format of the task directory block (TDB) . 



Hex. 



Byte 
>00 
>02 
>04 
>06 
>08 
>0A 
>0C 
>0E 



* 
>10 * 



LENGTH OF TASK SEGMENT 


FLAGS 


RECORD NUMBER 


DATE INSTALLED 


LOAD ADDRESS 




OVERLAY LINK j PRIORITY 




PROC 1 ID | PROC 2 ID 


TASK LENGTH 



+ .+ 

I FLAGS 1 

+ + 

| RECORD NUMBER | 

j DATE INSTALLED | 

+ + 

| LOAD ADDRESS 1 

+ + + 

I 

! 
+ + + 



Figure 4-11 Task Directory Block 
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Hex. 
Byte 

>00 
>02 



>04 



>06 



>08 



>0A 



>0B 
>0C 
>0D 
>0E 

>10 



Description 

Length of task segment in bytes. Length of task root 
plus the length of the tasks longest overlay path. 

Flags, which mean the following when set: 

Bit Meaning When Set 

Privileges 

1 System 

2 Memory resident 

3 Delete protected 

4 Replicatable 

5 Procedure 1 is on the system program file 

6 Procedure 2 is on the system program file 

7 Directory entry in use 

8 Overflow 

9 Writable control store 
10 Execute protected 
11-15 Unused (set to zero) 

Record number. Logical record number of the start of 
the task image in the program file. 

Date installed. Date is in the format: 

Bit Meaning When Set 

0-6 Year (Displacement) 
7-15 Julian date 

Load address. Relative starting address within a mapped 
task segment. Must be on a beet boundary. 

Overlay link. The ID of the most recently installed 
overlay associated with the task. Each overlay entry is 
in turn linked to the next entry so that tasks can be 
associated with their overlays when status or delete 
commands are executed. A value of is used to 
terminate the list. 

Priority of the task. 

Procedure 1 ID. 

Procedure 2 ID. 

Length (in bytes) of the difference between the last 
defined location and the first defined location of a 
task. If a BSS is the last instruction in the task, its 
length is not included in this value. 
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Figure 4-12 shows the format of the Procedure Directory Entry. 



Hex. 

Byte 



>00 



>02 



>04 



>06 



>08 



>0A 



LENGTH OF PROCEDURE SEGMENT 
FLAGS 



RECORD NUMBER 
DATE INSTALLED 



+ + 



LOAD ADDRESS 
UNUSED (=0) 



>10 * 



Hex. 
Byte 

>00 

>02 



>04 



Figure 4-12 Procedure Directory Entry 



Description 

Length of procedure segment in bytes. 

Flags, which mean the following when set: 

Bit Meaning When Set 

0-1 Unused (set to zero) 

2 Memory resident 

3 Delete protected 
4-6 Unused (set to zero) 

7 Directory entry in use 

8 Unused (set to zero) 

9 Writable control store 

10 Execute protected 

11 Write protected 
12-15 Unused (set to zero) 

Record number. Logical record number of the start of 
the procedure image in the program file. 
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Hex. 

Byte 



>06 



>08 

>0A 
>10 



Description 

Date installed. Date is in the format: 

Bit Meaning When Set 
0-6 Year (Displacement) 
7-15 Julian date 

Load address. Relative starting address within a mapped 
procedure segment. Must be on a beet boundary. 

Unused. 



Figure 4-13 shows the format of the Overlay Directory Entry. 



Hex. 
Byte 

>00 



>02 



>04 



>06 



>08 



LENGTH OF OVERLAY SEGMENT 
FLAGS 



RECORD NUMBER 



DATE INSTALLED 



LOAD ADDRESS 



>0A 



>0C 



*. 
>10 * 



OVERLAY LINK 



TASK ID 



UNUSED (=0) 



Figure 4-13 Overlay Directory Entry 
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Hex. 



Byte Desc ri ption 

>00 Length of overlay segment in bytes. 

>02 Flags, which mean the following when set: 

Bit Meaning When Set 

Relocation bit map is present 

1-2 Unused (set to zero) 

3 Delete protected 

4-6 Unused (set to zero) 

7 Directory entry in use 

8-15 Unused (set to zero) 

>04 Record number. Logical record number of the starting 
address of the overlay image in the program file. 

>06 Date installed. Date is in the format: 

Bit Meaning When Set 
0-6 Year (Displacementf 
7-15 Julian date 

>08 Load address. Relative starting address within a mapped 
overlay segment. Must be on a beet boundary. 

>0A Overlay link to the next overlay. 

>0B Task ID of associated task. 

>0C-0F Unused (set to zero) . 

>10 * 
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4.3.4.2 Directory Files. Directory files are unblocked relative 
record files and always have a record length of one sector. 
Record of the directory file contains an overhead record. The 
remaining records in the file may contain one of the following 
types of data blocks: 

* File Descriptor Record (FDR) — every file cataloged in 
the directory is represented by an FDR, which describes 
the file and its location on the disk. 

* Alias Descriptor Record (ADR) — every alias of a file 
cataloged in the directory is represented by an ADR, 
which gives the location of the file and points to the 
FDR of the actual file. 

* Key Descriptor Record (KDR) — each key indexed file 
catalogued in the directory is represented by an FDR, 
which in turn points to a KDR. The key descriptor 
record describes all of the keys (1-14) that are defined 
for the file. Note that the use of the KDR implies that 
each key indexed file cataloged in a directory uses two 
directory entries. 

Figure 4-14 shows the general structure of a directory file. 
Entries are made in the directory file by hashing the name of th# 
file being entered. The hash algorithm results in a recoM 
number from one through n, where n is the last record in the 
directory file. 

Figure 4-15 shows the hash algorithm. If the directory file 
record is unused, an FDR for the file being inserted is placed in 
that record. If the record is already used, a free record is 
found by a linear search from the hashed record. 
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RECORD NO. 

o 
1 



OVERHEAD RECORD 



S DIRECTORY ENTRIES 



2278135 



Figure 4-14 Directory File Structure 



939153-9701 



4-35 



Disk Organization 



System Design Document 



2278107 



( HASH J 



KEY- 1 

I 1 



C 

NAME(I) 




KEY- 


((KEY*C)MOD N)+t 




1 


' 


r 




1- 1 + 1 














WHERE 

N = NUMBER OF RECORDS IN 
THE DIRECTORY LESS 1 . 



Figure 4-15 Computing Hash Key 
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If the file being inserted is a key indexed file, another 
directory record must be found to contain the key descriptor 
record. This record is found by searching linearly from the file 
descriptor record for the file. The key descriptor record is 
inserted in the first available directory record following the 
file descriptor record. 

The different types of directory records are described in the 
following paragraphs. 

The directory overhead record (record of all directories) 
contains: 

* The maximum number of records (entries) in the 
directory. 

* The number of currently defined files. 

* The number of available records (entries) . 

* The filename of the directory. 

* The level number of the directory in the disk hierarchy 
(VCATALOG) is level 0) 

* The filename of the parent directory. 

* • The default physical record length. 

Figure 4-16 shows the format of a directory overhead record. 
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Hex. 
Byte 

>00 I DORNRC — NUMBER OF RECORDS IN DIRECTORY 

+ . 

>02 | DORNFL — NUMBER OP PILES IN DIRECTORY 

+ , , 

>04 | DORNAR ~ NUMBER OF AVAILABLE RECORDS 

+ 

>06 |DORTFC — NUMBER OF TEMPORARY FILES CURRENTLY DEFINED 
>08 



DORDNM — FILE NAME OF THIS DIRECTORY 
~ (8 ASCII CHARACTERS) 

I 1 



>10 I DORLVL — LEVEL NUMBER OF DIRECTORY 

>12 



+ + 



DORPNM — FILE NAME OF PARENT 
~ (8 ASCII CHARACTERS) 
>14 | , 

+ J 

>1A I DEFAULT PHYSICAL RECORD LENGTH I 

+ 1 

>1C | | 

RESERVED 



* ; 

>40 * 

Figure 4-16 Directory Overhead Record Format 
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Each file cataloged under the directory is represented by a file 
descriptor record. Figure 4-17 shows an FDR. 

Hex. 
Byte 

>00 

>02 

>04 



+- 

I 
+- 



FDRHKC — HASH KEY COUNT 
FDRHKV — HASH KEY 



FDRFNM — FILE NAME 
(8 CHARACTERS) 



•+ 

I 

-+ 



>0C 

>10 
>12 
>14 
>16 
>18 
>1A 
>1C 
>1E 
>20 

>24 

>28 



+- 

I 

+- 

I 

+- 

i 

+- 

I 
+- 

I 

+- 

I 
+- 

I 
+- 

! 

+- 



FDRPSW — PASSWORD (4 CHARACTERS) 
(NOT IMPLEMENTED) 



FDRFLG — FLAGS 
FDRPRS — PHYSICAL RECORD SIZE 
FDRLRS — LOGICAL RECORD SIZE 
FDRPAS — PRIMARY ALLOCATION SIZE 
FDRPAA — PRIMARY ALLOCATION ADU 
FDRSAS — SECONDARY ALLOCATION SIZE 
FDRSAA — OFFSET TO SECONDARY ALLOCATION TABLE 
FDRRFA — RECORD NUMBER OF FIRST ALIAS 
FDREOM — END OF MEDIUM LOGICAL RECORD NUMBER 



+- 

I 
+- 



FDRBKM — END OF MEDIUM BLOCK NUMBER 
FDROFM — END OF MEDIUM OFFSET 



-+ 

! 

■+ 

I 
•+ 

i 
-+ 

I 
-+ 

I 

-+ 

! 
-+ 

! 
-+ 

I 
-+ 



-+ 

I 
-+ 



Figure 4-17 File Descriptor Record — Part 1 of 2 
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Hex. 
Byte 



>2A 



>2E 



>30 



>32 



>34 



>36 



FDRFBQ — FREE BLOCK QUEUE HEAD 



FDRBTR — BLOCK NUMBER OF B-TREE ROOTS 
FDRSBB — BLOCK NUMBER OF FIRST BUCKET 
FDRTNB — TOTAL NUMBER OF BUCKETS 



■+ — + 



-+ SEE 

| NOTE 
■+ 1 



FDRKDR — RECORD NUMBER OF KEY DESCRIPTORS 
FDRUD — RESERVED FOR LAST UPDATE DATE 



>3C 



>44 



>46 



>48 



>84 



>86 



FDRCD — RESERVED FOR CREATION DATE 



+ + ; 

>42 I FDRAPB — ADUs/BLOCK | FDRBPA — BLOCKS/ADU I 



FDRMRS — MINIMUM RECORD SIZE 
FDRSAT — SIZE OF SECONDARY ALLOCATION 



STARTING ADU OF ALLOCATION 



SIZE OF SECONDARY ALLOCATION 
STARTING ADU OF ALLOCATION 



■+ — + 



SEE 
NOTE 
2 



Figure 4-17 File Descriptor Record — Part 2 of 2 

NOTE 1 — Used only for key indexed files. 

NOTE 2 — Secondary allocation table (up to 16 allocations). 
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Hex. 
Byte 

>00 



>02 



Field 

Name 



FDRHKC 



FDRHKV 



>04 
>0C 

>10 



FDRFNM 
FDRPSW 
FDRFLG 



De scription 

Hash Key Count. The number of file descriptor 
records (which may or may not include this 
one) that are present in the directory that 
hashed to this record number. 

Hash Key. The result of the hash algorithm 
for the file name actually covered in this 
record. The value might not be this record 
number since the data may have arrived here 
via the linear search used when the hashed 
address is occupied. 

File Name. Eight characters. 

Password. A future feature. 

Flags as follows: 



Bit 
0-1 



2-3 



Meaning When Set 
File usage flags: 

00 No special usage 

01 Directory 

10 Program File 

11 Image File 

Data Format: 

00 Binary 

01 Blank suppressed 

10 Reserved for ASCII & print form control 

11 Reserved 

Allocation type: 

Bounded 

1 Unbounded 



5-6 



File type: 

00 Reserved (for device) 

01 Sequential 

10 Relative record 

11 Key indexed 

Write protection flag: 

Not write protected 

1 Write protected 
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Hex. Field 

B y te Name Description 

Bit Meaning When Set 

8 Delete protection flag: 

Not delete protected 

1 Delete protected 



9 Temporary file flag: 

Permanent flag 

1 Temporary flag 

10 Blocked file flag: 

Blocked 

1 Unblocked 

11 Alias flag: 

Not an alias 

1 An alias file name 

12 Force write flag: 

Write buffers when memory is required 

1 Write buffers when updated 

13 Reserved for FCB changed flag (see 6.4) 

14 KIF marked during partial logging 

15 Reserved 

>12 FDRPRS Physical record size in bytes. Must be an 

even number. 

>14 FDRLRS Logical record size in bytes. Must be an even 

number if the file is unblocked. 

>16 FDRPAS Primary allocation size in ADU. 

>18 FDRPAA Primary allocation starting ADU number 

(starting disk address). 

>1A FDRSAS Secondary allocation size in ADU. 

>1C FDRSAA Offset into this FDR of the secondary 

allocation table, if any. No secondary 

allocation table is denoted by 0. Secondary 

allocations are present only for unbounded 
files. 
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Hex. 
Byte 



>1E 



Field 

Name 



FDRRFA 



Descri p tion 

Record number with the directory of first 
alias name. Files may be known by alias 
names. The alias names are noted in the 
directory in alias descriptor records. These 
alias descriptor records are chained to the 
actual FDR and each contains a pointer back to 
the actual FDR. 



>2Q FDREOM The logical record number of the end of 

medium. The end of medium is the end of the 
last space allocated to the file. 

>24 FDRBKM The logical block number of the end of medium. 

A logical block is the same as a physical 

block. 
>28 FDROFM The offset into the end of medium block of the 

logical record following the end of medium 

record. 



>2A 



FDRFBQ 



>2E 



FDRBTR 



>30 


FDRSBB 


>32 


FDRTNB 


>34 


FDRKDR 



>36 



FDRUD 



Block number of the first block in a queue of 
key indexed file free (unused) blocks. Each 
block points to the next block in the queue (a 
block is a physical record of the file) . Only 
used for key indexed files. 

The block number for the B-tree root block of 
the primary key. The block following this is 
the KIF root block for key 2, and so on. This 
field is also the total number of blocks that 
can be used for logging. 

The block number for the first KIF bucket. 

The total number of buckets in the KIF file. 

Record number of the directory file record 
containing descriptions of the KIF keys. 

Date of the last update to this file. The 
date is made up of three words. Word 1 
contains the binary value of the year. Word 2 
contains a value that is two times the number 
of days (counting from the beginning of the 
calendar year) ; the least significant bit is 
the most significant bit of word 3 of the 
date. Word 3 contains the number of seconds 
from the beginning of a day. 
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Hex, 
Byte 

>3C 



Field 
Name 



FDRCD 



>42 


FDRAPB 


>43 


FDRBPA 


>44 


FDRMRS 



>46 



FDRSAT 



>86 



Descri ption 

Creation date of the file. The date is made 
up of three words. Word 1 contains the binary 
value_ of the year. Word 2 contains a value 
that is two times the number of days (counting 
from the beginning of the calendar year) ; the 
least significant bit is the most significant 
bit of word 3 of the date. Word 3 contains 
the number of seconds from the beginning of a 
day. 

The number of ADUs per physical record. 

The number of physical records per ADU. 

The minimum size that a key indexed file 
logical record can be and still contain all of 
the keys defined. 

The secondary allocation table, which contains 
16 2-word entries. The first word of an entry 
contains the size, in ADUs, of the secondary 
allocation. The second word contains the 
starting ADU of the allocation. The tablf 
allows up to 16 files, and is only used if th| 
file was created expandable (unbounded) . The 
entry fields are filled in by file management 
as the file is expanded. 



Files can be given other names, each name being a separate alias. 
Each alias is hashed to find an entry in the directory just like 
a file name, and an alias descriptor record (ADR) inserted in 
that entry. The ADR points to the real file. It also points to 
the next alias for the file. Figure 4-18 shows the format of an 
ADR. 
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Hex. 
Byte 



>04 



>0C 



>22 



>86 



>00 I ADRHKC — HASH KEY COUNT 

+ 

>02 I ADRHKV — HASK KEY VALUE 



ADRFNM — FILE NAME 



+- 



ADRPSW — PASS CODE 



+ 

>10 I ADRFLG — FLAGS 



>12 I PHYSICAL RECORD SIZE 
+ ■ 



>14 LOGICAL RECORD SIZE 



>16 | PRIMARY ALLOCATION SIZE | SEE 

+ + NOTE 

>18 | PRIMARY ALLOCATION ADDRESS | 

+ + 

>1A | SECONDARY ALLOCATION SIZE | 

>1C J SECONDARY ALLOCATION ADDRESS | 

+ +- 

>1E | ADRRNA — RECORD NUMBER OF NEXT ALIAS | 
+ + 

>20 I ADRRAF — RECORD NUMBER OF ACTUAL FILE J 



UNUSED 



* 



Figure 4-18 Alias Descriptor Record 
NOTE 1 — Used to maintain ADR for compatibility. 
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Hex. 
Byte 

>00 
>02 
>04 



Field 
Name 



ADRHKC 



ADRHKV 



ADRFNM 



>0C 



>10 



ADRPSW 



ADRFLG 



>12->1D 

>1E ADRRNA 



>20 

>22->85 
>86 



ADRRAF 



Description 

Hash Key Count. The hash key 
same as in the file descriptor 



count 
record. 



is 



the 



Hash Key Value. The hash key value is the 
same as in the file descriptor record. 

File Name. The file name given in this item 
is an alias name for the file. In other 
words, it is a secondary name by which a 
previously defined file will also be known. 
The primary name for a file is supplied in the 
file descriptor record; secondary names are 
documented in alias descriptor records. 



Passcode. Space is provided for 
implementation of password codes. 



future 



Flags. The flag values are the same as 
provided in the file descriptor record. Note 
that the flag for alias is set to a one in 
this particular record. 

These fields are not used. 

Record Number of Next Alias. This is a" 
pointer chaining forward to another alias 
descriptor record for the same file, if any 
exists. A value of zero is provided to 
indicate the end of the chain; that is, no 
more alias descriptor records exist for the 
file. 

Record Number of Actual File. This is a 
pointer to the directory file record 
containing the file descriptor record for this 
particular file. 

Unused. These bytes may contain non-zero 
values, but they are not used. 



A key descriptor record (KDR) is used only for key indexed files. 
JL 2?? crib 5? the ^ eys (up to fourteen) used to access records in 
the .file. When a key indexed file is created and its keys are 
aetmed, a file descriptor record is hashed into the directory. 
File utility then performs a linear search for an unused 
directory record, starting from the file descriptor record. The 
KDR is placed in the first available directory record. Fiqure 4— 
19 shows the format of a KDR. 
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Byte 

* * 

>00 | HASH KEY COUNT | 

+ + 

>02 | -3 | 

+ . + 

>04 | NOT USED | 

+ + 

>06 | NUMBER OF KEYS | 

+ + + — + 

>08 i FLAGS | CHARACTER COUNT OF KEY 1 | SEE 
+ + + NOTE 

>0A 1 OFFSET TO KEY 1 | 1 

+ + — + 

>0C [ [ 

I I 

+ + -j. 

>3C j FLAGS | CHARACTER COUNT OF KEY 14 | 
+ + + 

>3E | OFFSET TO KEY 14 | 

* * 

>40 * 

Figure 4-19 Key Descriptor Record (KDR) 

NOTE 1 — For the primary key; repeat for each secondary key. 

Hex. 

Byte Description 

>00 Hash Key Count. This is the same as described for the 
file descriptor record. 

>02 Hash Key = -3. This field is similar to that provided 
with the file descriptor record. The value of -3 is 
given to indicate that this record is a key descriptor 
record and, therefore, is unavailable for use as a file 
descriptor record. 

>04 Not used. 

>06 The number of unique keys defined for this key indexed 
file. There are a maximum of 14 keys available for any 
key indexed file. There must be at least one key, the 
primary key. Keys 2-14, if any, are secondary keys. 
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Hex. 

Byte D escr i ption 

>08 Flags, as follows: 

Bit Meaning When Set 

0-2 Must be zero 

3 File is using partial logging, primary 
key only 

4 File was created by a system using the 
sequential placement scheme (primary key 
only) 

5 The key value need not always be 
present; that is, the key is modifiable. 
(Applies to secondary keys only.) 



>09 



6 Sequential commands are desired on this 
key, for example: Read Next 

7 Duplicates are allowed on this key 



The key length, in bytes (characters), of th< 
primary key. 



>0A The starting byte number for the position of 

the key within the key indexed file data 
record. The prior three items (flags, 
character count of key, and key offset) are 
repeated for each secondary key. 

>40 * 

Figure 4-20 shows a dump of the directory file .JB.DIR. The 
directory contains a sequential file (. JB.DIR. SEQ) , an image file 
(.JB.DIR. IMAG) , a program file (.JB.DIR. PROG) , and a key indexed 
file_ (.JF.DIR.KEY) . The directory also contains an alias for the 
key indexed file. The directory was created to have 11 entries, 
in addition to record which is the directory overhead record. 

4.3.4.3 Image Files. Image files are nonexpandable, unblocked 
relative record files that contain memory images of programs. 
They are not organized in any format; that is, each sector of the 
image file, starting with the first sector, is completely filled 
with data. There are no overhead records or words. Image files 
are designed so that a program image can be read into memory in a 
single disk access. 
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FILE:. JB.DIR RECORD? O00OO0 -- _ 

0000 OOOB 0004 0005 0000 4449 5220 2020 2020 ........ DI R 

0010 0002 4A42 2020 2020 2020 0000 0000 0000 . . JB 

SAME 
0OS4 0000 

FILE:. JB.DIR RECORD: 000001 _ . 

00*6 0OO2 0001 5345 5120 2020 2020 OOOU . . . . SE 

0094 0000 1A00 0120 002S 0001 016E 0001 0000 « 

00A4 0000 0000 OOOO OOOO 0000 0000 0000 OOOO ■ • • 

0OB4 OOOO OOOO OOOO OOOO 07B9 01D4 7E49 07B9 .. I •• 

00C4 0104 7E49 0103 OOOO OOOO OOOO OOOO OOOO .- -I 

SAME 
010A OOOO 

FILE:. JB.DIR RECORD". 000002 
010C OOOO 0001 494D 4147 2020 2020 OOOO . . . . IM AG 

011A OOOO C420 0120 0120 0004 1065 0001 OOOO • 

012A OOOO OOOO OOOO OOOO OOOO OOOO OOOO OOOO 

013A OOOO OOOO OOOO OOOO 07B9 01D4 7E38 07B9 

014A 010* 7E3B 0103 OOOO OOOO OOOO OOOO OOOO . 

SAFE' 
0190 OOOO 

FILE:. JB.DIR RECORDI000003 
0192 OOOO OOOO OOOO OOOO OOOO OOOO OOOO • • ■ • 

SAME 
0216- OOOO 

FILE:. JB.DIR REC0RD:0O0OO4 
0218 OOOO OOOO OOOO OOOO OOOO OOOO OOOO 

SAME 
029C OOOO 

FILEs.JB.DIK RECORDS 000005 
029E OOOO OOOO OOOO OOOO OOOO OOOO OOOO • « • • « • 

SAME 
0322 OOOO 
FILE:. JB.DIR RECORD: 000006 

0324 OOOO OOOO OOOO OOOO OOOO OOOO OOOO 

SAME 
03AS OOOO 

FILE:. JB.DIR REC0RD:000OO7 
03AA 0001 0007 5052 4F47 2020 2020 OOOO .... PR OO 

03BS OOOO SC20 0120 0120 001D 24A9 0001 OOOO * 

03CS OOOO OOOO 004A OOOO 004A OOOO OOOO OOOO J • • .J 

0308 OOOO OOOO OOOO OOOO 07B9 01D4 7E73 07B9 

OSES 01D4 7E77 0103 OOOO OOOO OOOO OOOO OOOO 

SAME 
042E OOOO 
FILES. JB.DIR RECORDS 000003 

0430 OOOO OOOO OOOO OOOO OOOO OOOO OOOO 

SAME 

04B4 OOOO 

FILES. JB.DIR RECORDS000009 

04B6 0001 0009 4B45 5946. 494C 4520 OOOO . . . . KE YF IL t .. 

04C4 OOOO 1E13 OOOO OOOO OOOO OOOO OOOO OOOO 

04D4 OOOO OOOA OOOO OOOO OOOO OOOO OOOO OOOO 

SAME 

053A OOOO 

FILES. JB.DIR RECORDsOOOOOA 

05^C 0001 OOOA 4B45 5920 2020 2020 OOOO . . . . KE Y 

054A OOOO 1E03 0120 0050 00 IB 248E 0002 OOOO P ..*... .. 

055A 0009 OOOO OOOO OOOO OOOO OOOO OOOO 004E N 

056A 0027 0029 0025 OOOB 07B9 01D4 7E1D 07B9 . - .) .7. 

0S7A 01D4 7E1C 0103 0009 OOOO OOOO OOOO OOOO 

SAME 

03C0 OOOO 

F I LE s . JB . D I R RECORD : OOOOOB 

05C2 OOOO FFFD 0064 0002 ! 04 OOOO 0005 

05D0 0004 OOOO OOOO OOOO OOOO OOOO OOOO OOOO 

SAME 

0646 OOOO 

2278136 

Figure 4-20 Directory File Dump 
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Section 5 
System Files 



5 . 1 GENERAL 

This section describes the structure and purpose of various files 
used by DX10 . These special files are: 

* System program file 

* System overlay file 

* Crash file 

* Roll file 

The files used by the System Command Interpreter are discussed in 
the section on SCI. 



5.2 SYSTEM PROGRAM FILE 

The system program file has the same structure as a general 

program file, as described in the section on disk data 

structures. It is called the system program file because it 

contains all of the disk resident system tasks and their 
overlays, as well as many utility programs. 

Queue-serving system tasks on the system program file include: 

* SLMFOT — System log message formatting and output task 

* TM$SBD — Scheduled Bid Task SVC processor 

* TM$DGN — Termination task 

* SVCKIL — Kill TASK SVC processor 

* PF$LIN — Install Task, Procedure, and Overlay SVC 
processor 

* PF$LDE — Delete Task, Procedure, and Overlay SVC 
processor 

* FUTIL — File Utility SVC processor 
939153-9701 5-1 
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* PF$LMN — Map Name to ID SVC processor 

* PF$LAS — Assign Space on Program File SVC processor 

* INSTAL — Install, Unload, Initialize Volume SVC 
processor 

5.3 SYSTEM OVERLAY FILE 

The system overlay file is an unblocked relative record file used 
to contain system overlays. Each overlay is placed in the record 
that corresponds to the overlay number, and is 
format. Each record is 800 bytes. 



in memory image 



When a system overlay is requested, the record that corresponds 
to the required overlay number is read directly into one of the 
system overlay areas by the system overlay loader, thus incurring 
very little overhead. 

Table 5-1 shows what overlays are contained on the system overlay 
file. 



£ 



1 

2 

3 

4 

5 

6 

7 

8 

9 

A 

B 

C 

D 

E 

F 

10 

11 

12 

13 

14 

15 

16 

17 



Name 

TM$0V1 
OLN005 
OLN006 
OLN007 
OLN00A 
OLN00B 
OLN00C 
FMOV10 
FMOV11 
FMOV12 
FMOV13 
DMOV0D 
DMOV0E 
DMOV0F 
DMOV14 
TM$RWO 
TM$BOV 
PLGERR 
OLN001 
OLN002 
OLN003 
OLN004 
OLN008 
OLN009 



Table 5-1 System Overlay Numbers 

Description 

TM$BID Error Recovery 
KIP Seq., Split in a B-Tree 
KIF Seq. , Insert a Record 
KIF Seq. , Rewrite a Record 
KIF Seq., Open/Close Processor 
KIF Seq. , Delete a Record 
KIF Seq. , Delete 



a B-Tree Entry Overlay 
File Management, Rewrite, Space 
File Management, Write EOF, Rewind, Unlock 
File Management 
File Management, Open Extend 
Disk Manager 
Disk Manager 
Disk Manager 
Disk Manager 
Task Manager 
Task Manager 

KIF Seq. , Error Recovery 
KIF Hash, B-Tree Split 
KIF Hash, Insert 
KIF Hash, Rewrite 
KIF Hash, Open Random and Close 
KIF Delete Record Overlay 
KIF Delete B-Tree Overlay 
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5.4 CRASH FILE 

The system crash file, .S$CRA3H, is an image file created large 
enough to contain a dump of all memory. When a system crash 
occurs, the routine SCRASH displays the crash code on the front 
panel lights and idles the CPU. If a dump is taken, SCRASH 
writes all of memory to the file .S$CRASH. This file may later 
be used as input by the crash analysis program, ANALZ. 



5.5 ROLL FILE 

The roll file is an expandable image file that is used to contain 
rolled-out task and procedure images. It is created by the CSF 
(Create System Files) command. 

There is no single directory of roll file entries. Instead, a 
linked list of the TSBs and PSBs of rolled tasks and procedures 
is maintained. Each TSB and PSB contains the starting record 
number and number of roll file records used by that segment. 
When the roll allocation routine, TMRDAL, searches for a block of 
free roll file space, it runs down the list until it finds a hole 
between segments, or space between the last rolled segment and 
the end of the file, large enough to fill the request for roll 
space from the task loader. The roll file may be extended, if 
necessary. 
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Section 6 
Data Structures 



6 . 1 GENERAL 

Memory resident data structures within DX10 consist of many 
tables, queues, and buffers. Most of the tables and buffers are 
dynamically allocated from the system table area. Most of the 
system queues are anchored in the DX10 data base modules, DDATA 
and DXDAT2. The following paragraphs describe the important data 
structures used by DX10. 



6 . 2 QUEUES 

The general structure of a DX10 queue is described in Section 1. 

The queues are singly linked, first-in, first-out lists of data 
structures to be processed. A queue is established by a queue 
anchor, which is usually a 10-byte block having a format as shown 
in Figure 6-1. 



Hex. 
Byte 

* * 

>00 j QUENEW — NEWEST ENTRY | 

+ + 

>02 | QUEOLD — OLDEST ENTRY | 

+ _ + 

>04 | QUETSB — TSB OF SERVER TASK | 

+ _ + + 

>06 | QUEFLG — FLAGS j QUETID — SERVER ID | 

+ + + 

>08 J QUESTA — TASK STATE | QUECNT — NO. OF ENTRIES | 
* + * 

>0A * 



Figure 6-1 Queue Anchor 
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Hex. 
Byte 



>00 



Field 
Name 



QUENEW 



Description 

The address of the newest (last) entry on the 
queue. Note that since this is only a one- 
word address, it is implied that the queued 
structures are mapped in with the queue 
anchor . 



>02 

>04 



>06 



>07 

>08 

>09 
>0A 



QUEOLD 
QUETSB 



QUEFLG 



QUETID 



QUESTA 



QUECNT 



The address of the oldest (first) entry on the 
queue. 

The address of the task status block of the 
queue serving task (see paragraph 6.7 on 
TSBs) . This field is zero if no queue server 
exists for the queue, or if the queue server 
is not loaded into memory. 

Flags, which when set mean: 

Bit Meaning 

Priority ordered queue (TSBs with high 
priorities are at the front of the queue). 

1 TSB queue (entries are TSBs) . 
2-7 Reserved. 



The installed ID of the queue serving 
(zero if no server). Queue servers mus 
installed on the system program file. 



tasi 
t bl 



The task state that is to be assigned to all 
TSBs that are placed in this queue (=>FF if 
none) . 

The number of entries currently in the queue. 



Most queue anchors are located in the module named DXDAT2. 
Section 7 for further information about DXDAT2. 



See 



6.3 PHYSICAL DEVICE TABLE 

A Physical Device Table (PDT) is a data structure that represents 
a physical _ device to the operating system. In addition to 
containing information describing the device, the PDT is used as 
a workspace by the device service routine. Some of the uses of 
the PDT are discussed in Volume V of the DX10 reference manuals. 
A physical device table has the format shown in Figure 6-2. 
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Hex. 
Byte 

>00 

>02 

>04 

>06 

>08 

>0A 

>0C 

>0E 
>10 
>12 
>14 
>16 
>18 
>1A 

>1C 

>1E 

>20 

>22 



RO 

Rl 

R2 

R3 

R4 

R5 

R6 

R7 

R8 

R9 

RIO 

Rll 



PDTLNK — FORWARD LINK TO NEXT PDT 
PDTMAP — POINTER TO DSR MAP FILE 
PDTRO — DSR SCRATCH 



PDTPRB — PRB ADDRESS 
PDTDSF — DEVICE STATUS FLAGS 



PDTDTF — DEVICE TYPE FLAGS 
PDTDIB — DEVICE INFO BLOCK ADDRESS 



PDTR5 

PDTR6 

PDTR7 

PDTR8 

PDTR9 

PDTR10 

PDTR11 



DSR SCRATCH 



•+ 
i 

I 



- + 

I 

-+ 



R12| 


PDTCRU — CRD OR TILINE BASE ADDRESS 


R13| 


PDTR13 — SAVED WP REGISTER 


R14| 


PDTR14 — SAVED PC REGISTER 


R15| 


PDTR15 — SAVED ST REGISTER 



Figure 6-2 Physical Device Table (Part 1 of 2) 
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Hex. 



Byte 


>24 


>26 


>28 


>2A 


>2E 


>30 


>32 


>34 


>36 


>38 



>42 
>44 
>46 
>48 



+ 

I 
+- 

I 
+- 

I 
* 



PDT$ -- PDT WORKSPACE ADDRESS 



| PDTDSR — DSR ADDRESS | 

+ „_ + _ ._ + 

! PDTERR — ERROR CODE j PDTFLG — FLAGS | 
+ _ + + 



PDTNAM — DEVICE NAME 



PDTBLN — BUFFER LENGTH 
PDTINT — DSR INTERRUPT ADDRESS 



PDTM1 — TIME OUT COUNT 1 

PDTM2 — TIME OUT COUNT 2 

PDTSRB — SAVED PRB ADDRESS 



PDTSL1 — CONTROLLER IMAGE FOR SYSTEM LOG 1 | 
+ 

PDTSL2 — CONTROLLER IMAGE FOR SYSTEM LOG 2 | 

+ 

PDTBUF — NOT USED I 




Figure 6-2 Physical Device Table (Part 2 of 2) 



Hex. 
Byte 

>00 



>02 

>04 

>06 



Field 
Name ~ 



PDTLNK 



PDTMAP 
PDTRO 



Description 

Address of the next PDT and the PDT expansion 
block for this PDT. All the PDTs are linked 
in a single list that is located in the D$DATA 
module. 

Address of the DSR map file. 

This word begins the workspace to be used by 
the device service routine initial entry 
processor . 



PDTPRB Address of buffered I/O supervisor call bloc! 
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Hex. 
Byte 

>08 



Field 
Name 



PDTDSF 



Description 

Device status flags that are set by the 
system: 



Bit 



Meaning When Set 



1 
2 
3 

4 
5 



Device is open 
assigned to th 
Device is busy 
Kill I/O at th 
Task doing I/O 
killed. 

Make this devi 
at the end of 
Signals the ta 
the DSR. This 
to wait for 
flag and then 
Data transfer 
end-of-record 
done for this 
= ASCII. 1 



ed; that 
e device. 



is 



LUNOs are 



is device is in progress, 
at this device is being 

ce available (unassigned) 

this I/O operation. 

sk scheduler to reenter 
flag can be used by a DSR 
a device, by setting the 

returning to the system. 
is complete, therefore 
processing 

device. 

= JISCII. 



needs to be 



>09 



Interrupt mask to be used by the DSR. This 

field is the interrupt level assigned to the 

device minus one, and is set at system 
generation time. 
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Hex. 
Byte 



>0A 



Field 

Name 



PDTDTF 



>0C 



PDTDIB 



Desc ription 

Device type flags that are all set at system 
generation time except for the system disk 
flag that is set by the system loader. 

Bit Meaning When Set 

~ File oriented device (IF" the flag is 

zero, the device is record oriented.) 

1 Device uses the TILINE data bus. 

2 The time-out logic should be enabled 
for this device. 

3 Device may only be used by privileged 
tasks. 

4 This is a terminal (keyboard device) 
with a keyboard status block attached 
to the PDT. 

5 This is a communications device. 

6 This is the system disk. 

7 A PDT extension exists. 
8-11 Not used. 

12-15 Device type code, as follows: 

— Dummy 

1 — Teleprinter 

2 — Line Printer 

3 — Cassette 

4 ■ — Card Reader 

5 — Video Display Terminal 

6 — Disk and Diskette 

7 — Communications 

8 — Magnetic Tape and AMPL 
E — AMPL Emulator 

F — AMPL Trace Module 

Pointer to the word after the PDT itself. 
This may be the address of the keyboard status 
block (KSB) , disk PDT extension (DPD) , tape 
PDT extension (TPD) or line printer PDT 
extension (LPD) depending upon the tvpe of 
device. 
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Field 



Byte 


Name 


>0E 


PDTR5 

through 

PDTRll 


>1C 


PDTCRU 


>1E 


PDTR13 




PDTR14 




PDTR15 


>24 


PDT$ 


>26 


PDTDSR 


>28 


PDTERR 


>29 


PDTFLG 



>2A 


PDTNAM 


>2E 


PDTSL1 , 




PDTSL2 



>32 
>34 

>36 



PDTBUF 
PDTBLN 

PDT INT 



Description 
Scratch registers to be used by the DSR. 

The CRU or TILINE address of the device. 

These three words contain the saved context 

(WP, PC 

ST) to which the DSR returns control via a 

RTWP. 



Pointer to the beginning of the PDT workspace; 
that is, byte 4 of the PDT. 

A pointer to the beginning of the DSR. 

Error code returned by the DSR. 

Device flags as follows: 

Bit Meaning When Set 

8 Use PRB in log message. 

9 Receive mode for JISCII. 
10 Transmit mode for JISCII. 

11-12 Device state: online = 00, offline = 01, 

diagnostic = 10. 
14 Operation failed bit. 

The 4-character device name. 

For CRU devices, these words contain the 

controller 

image after an error. For TILINE devices, 

these words contain a pointer to the 

controller image after an error. 

Not used. 

Maximum length of a data buffer which may be 
transferred by the device in an I/O operation, 
for example, 80 for a card reader. This is 
only necessary for CRU devices. 

The interrupt entry address of the DSR and 
reen te r-me-addre ss . 
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Hex. 



Field 



Byte Name 
>38 PDTDVQ 



>42 PDTM1 
>44 PDTM2 



>46 



>48 



PDTSRB 



D escription 

The anchor for the queue of I/O requests for 
this device. The anchor has the same format 
as the queue anchor described in paragraph 
6.2. 

The number of system time units in the time- 
out count for the device. 

The number of time units remaining in the 
time-out count before the system assumes that 
a device error has occurred. When the DSR 
starts an I/O operation, it should move the 
time-out count in bytes >42->43 to this word. 
This word is then used by the scheduler as the 
time-out counter. Each time a system time 
unit has elapsed, the scheduler decrements the 
time-out count and sets the time-out enable 
flag (bytes >0A->0B) . If the counter goes to 
zero before a device interrupt occurs (and the 
DSR resets the counter or the flag), the 
system assumes that a device error has 
occurred and reports it. 



The address of the queued supervisor ca 
block, plus two (offset to PRB; see the DX 
Operating System Systems Programming Guide' 



i 



6-8 



939153-9701 



System Design Document 



Data Structures 



All PDTs must be defined during system generation. The PDTs are 
concatenated and inserted into the D$DATA module by GEN990. 

Under DX10 , PDTs for disks and terminals each have an extension 
that is used mainly by the interrupt processing routine of the 
DSR. The following paragraphs describe those extensions. 

6.3.1 PDT Expansion Block 

Every PDT has a 10-byte expansion block. The end of this block 
is pointed to by the link to the next PDT (PDTLNK) . In the case 
of the last PDT (DS01) where the link is zero, PDTLST in ROOT 
points to the expansion block. The format of the PDT expansion 
block is shown in Figure 6-3 . 



Hex. 



Byte 


>0A 


>08 


>06 


>04 


>02 



* * 

! RESERVED — SET TO ZERO | 

+ + 

| PDTRED — READ OPERATIONS COUNT | 

+ , , + 

I PDTWRT — WRITE OPERATIONS COUNT ! 
+ + 

| PDTOTH — OTHER OPERATIONS COUNT | 
+ + + 

JPDTRTY — RETRIES COUNT | PDTLUN — LUNOS COUNT | 



Figure 6-3 Physical Device Table Expansion Block 



Hex. 



Field 



Byte 


Name 


>0A 




>08 


PDTRED 


>06 


PDTWRT 


>04 


PDTOTH 


>02 


PDTRTY 


>01 


PDTLUN 



Desc r iption 

Reserved. Initialized to zero. 

The number of read operations that have been 
performed. 

The number of write operations that have been 
performed. 

The number of other operations that have been 
performed. 

The number of retries. 

The number of LUNOs assigned. 
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6.3.2 Disk PDT Extension (DPD) 

The extension that is appended to disk PDTs is 96 bytes long. 
The format is shown in Figure 6-4. 



Hex. 
Byte 



>48 
>4A 
>4C 
>4E 
>50 
>52 
>54 
>56 
>58 
>5A 
>5C 
>5E 
>60 
>62 



* + *_+ 

JDPDPRB — PILE MGMT PRB | DPDERR — ERROR CODE | 
+ + ,_ + 

| DPDPOP — OP CODE | DPDLUN — LUNO | 
+ + + 

| DPDSFG — SYSTEM FLAGS | DPDUFG — USER FLAGS | 
+ + ,„ + 

1 DPDBUF — BUFFER ADDRESS | 

+ , + + _ FILE 

MGMT 
I/O 



DPDRCL — RECORD LENGTH 
DPDCCT — CHARACTER COUNT 
DPDADU — ADU NUMBER 
DPDSCT — SECTOR OFFSET 



DPDWTK — WORDS/TRACK 

» + 

|DPDSTK — SECTORS /TRACK | DPDOHD — OVERHEAD/REC. 
+ + + 

I DPDCYL — HEADS AND CYLINDERS [ 

+ + __ + 

IDPDSRD — SECTORS/RECORD | DPDRTK — RECORDS/TRACK | 
+ + + 

I DPDWRD — WORDS/RECORDS j 

+ + 

DPDTIL — TILINE IMAGE 

(DPDILF — INTERLEAVING FACTOR) 
+ j 

Figure 6-4 Disk PDT Extension (Part 1 of 2) 



+ 

I 

+ 

I 
+-+ 

I 

+ 



SVC 
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Hex. 



Byte 

+ + 

>64 | DPDILF — INTERLEAVING FACTOR j 

+ , + 

>72 | | 

DPDIBF — INITIALIZATION BUFFER 

I ! 

+ + 

>78 | DPDFCB — POINTER TO VCATALOG FOB | 

+ . + 

>7A j | 

DPDVNM — VOLUME NAME 

I ! 

+ . — . + 

>82 | DPDFMT — FILE MANAGER TSB ADDRESS | 
+ + 

>84 | DPDFMW — FILE MANAGER TASK AREA ADDRESS | 
+ + 

>86 | DPDPBM — DISK MANAGER BUFFER ADDRESS 1 
+ _ __ + 

>88 | DPDMAD — MAXIMUM NO. OF ADUs ON DISK | 
+ . + 

>8A | DPDSAD ~ SECTORS /ADU | 

+ __ 1+ 

>8C S DPDDRS — DEFAULT PHYSICAL RECORD SIZE | 
+ + 

>8E | DPDECT — ERROR COUNT | 

+ + 

>90 | | 

= DPDTFL — TEMPORARY FILE NAME SEED 

I I 

+ . + 

>98 | | 

DPDSLG — TILINE IMAGE FOR SYSTEM LOG = 

I I 

+ + 

>A8 j DPDFLG -- FLAGS WORD | 

+ + 



Figure 6-4 Disk PDT Extension {Part 2 of 2) 
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Hex. 
Byte 


Field 
Name 


>48 
to 
58 


DPDPRB 

through 

DPDSCT 


>58 


DPDWTK 


>5A 


DPDSTK 


>5B 


DPDOHD 


>5C 


DPDCYL 



>5E 


DPDSRD 


>5F 


DPDRTK 


>60 


DPDWRD 


>62 


DPDTIL 


>64 


DPDILF 


>72 


DPDIBF 


>78 


DPDFCB 


>7A 


DPDVNM 


>82 


DPDFMT 



>84 



DPDFMW 



Description 

These 16 bytes are a copy of the file I/O 
supervisor call block. 



Number of words per track on the disk. 
Number of sectors per track. 



Number of overhead bytes per physical record 
(equal one sector). 

Number of heads and cylinders as follows: 

Bit Meaning 

0-4 Number of heads on the disk. 

5-15 Number of cylinders. 

Number of sectors per disk record (=1). 

Number of disk records per track. 

Number of words per record. 

An image of the eight TILINE controller 
registers for the disk. 

Interleaving factor, integer number 

The buffer used to hold information returned 
by the Store Registers direct disk I/O call. 

A pointer to the file control block for the 
disk volume directory (see paragraph 6.4). 

The 8-character name of the volume that is 
currently installed on the disk unit. 

The address of the task status block (see 
paragraph 6.7) for the file management task 
for this disk controller. 

The address of the file management task work 
area (see the section on D$DATA) . 
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Hex. 



Field 



Byte 


Name 


>86 


DPDPBM 


>88 


DPDMAD 


>8A 


DPDSAD 


>8C 


DPDDRS 


>8E 


DPDECT 



>90 
>98 

>A8 



DPDTFL 
DPDSLG 

DPDFLG 



Description 

The address of the disk manager buffer for 
this disk. 

The maximum number of ADUs on this disk. 

The number of sectors per ADU. 

The default physical record size for this 
disk, as defined to GEN990. 

A count of the number of controller errors 
returned. This count is reinitialized when 
the system is booted. 

The temporary file name last used. 

A copy of the TILINE image used by the system 
log. 

Flags as follows: 

Bit Me aning When Set 

DPFRTY — No retry desired. 

1 DPFRAW — Disk read after write. 

2 DPFBRW — Bit map read after write. 
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5.3.3 Teleprinter Device PDT Extension (DIB) 

The Device Information Block (DIB) is a data structure appended 

to the PDT that contains information about the current status of 

the device as well as information about how it was configured at 

system generation time. Figure 6-5 shows the format of the TPD 

extension. 



Hex. 
Byte 



* * 



>00 J ACU CRU ADDRESS 



+ ; 



>02 I ISR TYPE (COMM-1, TTY-5) 



+ + 

>03 I LINE CONTROL TYPE (ALWAYS 0) I 

+ 1 

>04 J READ ASCII TIMEOUT | 

+ . , , + 

>06 I WRITE TIMEOUT I 

+ ; 

>08 | READ DIRECT TIMEOUT 1 I 

+ _ 1 

>10 i READ DIRECT TIMEOUT 2 

+ 1 

>12 | SYSGEN ACCESS FLAGS I 

+ ___ I 

>13 | STATE FLAGS I 

+ _ J 

>14 I LINE FLAGS | 

+ 1 

>15 | TEMPORARY ACCESS FLAGS I 

+ J 

>16 | SPEED (ENCODED) I 

+ 1 

> 17 j END OF RECORD CHARACTER I 

+- J. 

>18 I END OF FILE CHARACTER I 

+ j 

>1 9 I LINE TURN AROUND CHARACTER I 

+ 1 

>20 j PARITY ERROR SUBSTITUTE ! 

+ j 



>21 ! CR DELAY INTERVAL 

+ 4. 

Figure 6-5 Teleprinter Device Extension to PDT (Part 1 of 2) 
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Hex, 

Byte 

+ + 

>22 | PARITY CHECK ROUTINE | 

+ +. f 

>24 | PARITY SET ROUTINE | 

+ + 

>26 j MAXIMUM CHARACTERS BUFFERED IN FIFO | 

+ + 

>28 | TERMINAL TYPE | 

+ + 

>29 j LAST CHARACTER RECEIVED j 

+ + 

>30 | SAVED EXTENDED FLAGS ] 

+ + 

>32 | SAVED ERROR CODE FROM ISR I 

+ + 

>33 | SPEED | 

+ + 

>34 | ISR VECTOR TABLE POINTER \ 

+ + 

>36 | TIMEOUT | 

+ + 

>38 1 NUMBER OF PARITY ERRORS | 

+ + 

>40 ] NUMBER OF LOST CHARACTERS j 

* * 



Figure 6-5 Teleprinter Device Extension to PDT (Part 2 of 2) 

Hex. Field 

Byte Name De scriptio n 

>00 The CRU address of the ACU. 

>02 The Interrupt Service Routine type, which is 

either communications (1) or teletype mode (5) 

>03 The line control type, which is always 0. 

>04 The Read ASCII timeout. 

>06 The Write timeout. 

>08 The Read Direct timeout 1. 

>10 The Read Direct timeout 2. 

>12 The sysgen access flags. 
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Hex. 

Byte Description 

>13 The state flags as follows: 



Bit 


Meaning 





Online 


1 


Connect in progress 


2 


Open 


3 


DLE received 


4 


Half-duplex line belongs to remote 




terminal 


5 


Re send flag 


6-7 


Unused 



>14 Line flags as follows: 

Bit Meaning 

Half-duplex modem 

1 Switched line 

2 Refuse call 

3 Auto-disconnect enable 

4 DLE/EOT for disconnect sequence 

5 SCF ready /busy monitor 

6 Pile transfer exclusive access 

7 Half-duplex LTA enable 

>15 The temporary access flags as follows: 

Bit Meaning 

No echo 

1 Unused 

2 Transmit parity enabled 
3-4 Transmit parity type 

00 = Even 

01 = Odd 

10 = Mark 

11 = Space 

5 Receive parity enabled 
6-7 Receive parity type 

>16 The speed (encoded) . 

> 17 The end of record character. 

>18 The end of file character. 

> 19 The line turnaround character. 

>20 The parity error substitute character. 
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Hex. 



Descri p tion 

The carriage return delay interval. 

The parity check routine pointer. 

The parity set routine pointer. 

The maximum characters buffered in FIFO. 

The terminal type. 

The last character received. 

The saved extended flags. 

The saved error code from interrupt 
service routine. 

The speed (specified at system generation) . 

The interrupt vector table pointer. 

The timeout (specified at system generation) 

The number of parity errors. 

The number of lost characters. 



6.3.4 Keyboard Status Block (KSB) 

Each keyboard type device supported by DX10 has a KSB appended to 
the PDT for the device. The KSB is generally used by the 
keyboard interrupt decoder of the device service routine. 
Special keyboard devices that are supported by user-written DSRs 
need not have a KSB unless the System Command Interpreter (SCI) 
is to be bid at the terminal, in which case the KSB must be 
present. Figure 6-6 shows the format of a KSB. 



Byte 


>21 


>22 


>24 


>26 


>28 


>29 


>30 


>32 


>33 


>34 


>36 


>38 


>40 
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Hex. 
B y te 

>00 
>02 
>04 
>06 
>08 
>0A 
>0C 
>0E 
>10 



RO 



Rl 



R2 



R3 



R4 



R5 



KSBLDT — STATION LDT ADDRESS 



KSBQOC ~ QUEUE LENGTH 
KSBQIP — QUEUE INPUT POINTER 



KSBQOP — QUEUE OUTPUT POINTER 
KSBQEP — QUEUE END POINTER 



RESERVED | 

+ + + 

R6 J KSBFL ~ KSB FLAG j KSBSN ~ STATION NO. I 



R7 



R8 



KSBR7 — SCRATCH 



KSBTSB — TSB ADDRESS/VALIDATION TBL ADDRESS 




>1A 
>1C 
>1E 

>20 

>22 

>24 

>26 

>28 

>2A 

>2C 



+- 

! 

+- 

I 
+- 

I 
+- 

I 
+- 

I 
*. 

* 



R13 KSBR13 — SAVED WP 

R14 KSBR14 — SAVED PC 

R15 KSBR15 — SAVED ST 

+ , 

I KSBLDO ~ PDT ADDRESS | 
+ + 

KSBLD2 — LUNO | KSBLD3 — START I/O CT| 



KSBLD4 — LDT FLAGS 
KSBLD6 — LDT LINK 



KSBLD8 — TSB ADDRESS 
KSBLCK — LOCK COUNT 



- + 

I 
-+ 

1 

-+ 



Figure 6-6 Keyboard Status Block 
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Hex. 



Field 



Byte 


Name 


>00 


KSBLDT 


>02 


KSBQOC 


>04 


KSBQIP 



Description 

The offset into the KSB of the logical device 
table (LDT) anchor for station (terminal) 
local LUNOs. 

The number of characters currently in the 
input character queue. 

A pointer to the next byte of the character 
queue that is available to receive an input 
character. 



>06 
>08 

>0A 
>0C 



KSBQOP 



KSBQEP 



RESERVED 



KSBFL 



A pointer to the oldest character in the input 
character queue, that is, the next character 
to be picked up by the DSR. 

A pointer to the word after the character 
queue. That word contains the length of the 
queue. 



Flags as follows: 



>0D 
>0E 
>10 



Bit Meaning When Set 

Character mode (no mapping) . 

1 Enable the command interpreter bid logic, 

2 Keyboard is in record mode (always set) . 

3 Bid the command interpreter. 

4 The command interpreter is active. 

5 Halt I/O. 

6 Abort I/O. 

KSBSN Station (terminal) ID. 

KSBR7 Scratch register for use by the DSR. 

KSBTSB The address of the TSB of the task currently 

using the terminal if the terminal is in 
character mode. If a validation table is 
being used, this field contains the validation 
table address. 
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Hex . 
Byte 

>12 



>18 



>1A 



>20 



Fiel d 
Name 

KSBR9, 
KSBR10 , 
KSBR11 



Description 
Scratch registers for use by the DSR 



>2A 



>2C 



KSBCRU The CRU address of the terminal. For VDTs, 
this address is >10 more than in the PDT. 

KSBR13 The saved context (WP, PC, ST) to which the 
DSR keyboard interrupt handling routine 
returns control via a RTWP instruction. 

KSBLDO These 10 bytes form a logical device table 
(see paragraph 6.5 on LDTs) that serves as an 
anchor for the terminal local LDT list, as 
described in Section 1. Flag bit in byte 
>24 is set to mark this LDT as an anchor. 
This LDT assigns terminal local LUNO to the 
terminal itself. 

KSBLCK The lock out count, which is a count of the 
number of Read With Event Characters SVCs 
issued for this terminal. 
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6.3.4.1 Video Display Terminal Extension (VDT) . The VDT is an 
extension to the KSB used by the 911 and 913 terminals. The 
offsets are expressed from the beginning of the Physical Device 
Table (PDT) to which the KSB has been appended. Figure 6-7 shows 
the format of the VDT extension. 



Hex. 
Byte 



>30 
>32 
>34 
>36 
>38 
>3A 
>3C 

>40 



>2C J VDTEUF — EXTENDED USER FLAGS I 

+ + + 

>2E I VDTFIL — FILL CHAR I VDTEVT — EVENT CHAR j 



VDTPOS — CURRENT CURSOR POSITION 
VDTDEF — START OF FIELD 



* 



VDTSC1 — SCRATCH 
VDTSC2 — SCRATCH 






VDTSC3 — SCRATCH 
VDTJIN — BIT MASK 



-+ 

I 

-+ 



UNUSED 






Figure 6-7 Video Display Terminal Extension to KSB 
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Hex. 
gyTe * 

>2C 



>2E 

>2F 

>30 
>32 
>34 
>36 
>38 
>3A 



Field 
Name 

VDTEUF 
VDTFIL 
VDTEVT 

VDTPOS 
VDTDEF 
VDTSC1 
VDTSC2 
VDTSC3 
VDTJIN 



De scriptio n 

The extended user flags to be used during the 
current operation. 

The fill character to be used during the 
current operation. 

The event character to be returned to the user 
call block. 

The current position of the cursor. 

The beginning of the field. 

Scratch field for use by the extension. 

Scratch field for use by the extension. 

Scratch field for use by the extension. 



>3C->3F 
>40 * 



A mask that is used to set bit 
character to the appropriate value. 

Not used. 



of 
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6.3.4.2 Electronic Video Terminal Extension (VDT94 0) . The 
VDT940 is an extension to the KSB used by 940 terminals. The 
offsets are expressed from the beginning of the Physical Device 
Table (PDT) to which the KSB has been appended. Figure 6-8 shows 
the format of the VDT940 extension. 



NOTE 

The meaning and position of the flags are for 
TI internal use only and may be moved, 
changed, or deleted at any time. 



The VDT940 has the following format: 

Hex. 
Byte 



* 



* 

>2C | VDTEUF — EXTENDED USER FLAGS j 

+ + + 

>2E j VDTFIL — FILL CHAR I VDTEVT — EVENT CHAR | 
+ + + 

>30 I VDTPOS — CURRENT CURSOR POSITION | 

+ + 

>32 | VDTDEF — START OF FIELD j 

+ + 

>34 j VDTRED — READ DIRECT WORD j 

+ _ + 

>36 | VDTSC1 ~ FLAG WORD 1 | 

+ + 

>38 | VDTSC2 — FLAG WORD 2 | 

+ + 

>3A 1 VDTSC3 — TEMP LINK SAVE LOCATION \ 

+ + + 

>3C | RESERVED |GENSPD — TERMINAL SPEED] 
+ + + 

>3E | RESERVED | 

+ + 

>40 |VDTATT — ATTRIBUTE SENT|VDTATB — ATTRIBUTE REC j 
+ + + 

>42 | VDTSC4 — TEMP LINK SAVE LOCATION ] 

+ + 

>44 ] VDTCNT — COUNT FOR VDTRED | 

+ _ + 

>46 | VDTPTR — POINTER TO PRINTER PDT | 

+ + 

Figure 6-8 Electronic Video Terminal 
Extension to KSB (Part 1 of 2) 
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Hex. 
Byte 

+ + 

>48 |VDTSC5 ~ LINK REGISTER (CHANGING CHARACTER SETS) | 

+ + 

>4A | VDTMFL — FLAG WORD FOR MODE FLAGS | 

+ , + 

>4C | VDTEDL — FLAG WORD FOR EVENT KEY FLAGS | 

+ . + 

>4E | VDTSIZ — NUMBER OF CHARACTER SCREEN MEMORY [ 

+ + 

>50 | VDTFIS — SAVE RO FOR FIFO | 

+ _ + 

>52 | VDTSC6 — TEMPORARY STORAGE | 

+ ,__ i+ 

>54 | FIFOCT — FIFO COUNT | 

+ + 

>56 | FIFOIP — FIFO INPUT POINTER | 

+ + 

>58 [ FIFOOP — FIFO OUTPUT POINTER | 

+ + 

>5A | FIFOEP — FIFO END POINTER | 

+ + 

>5C | FIFOBP — BEGINNING OF FIFO | 

+ + 

• » 

+ + 

! FIFOPT — FIFO LENGTH | 

+ f 

Figure 6-8 Electronic Video Terminal Extension to KSB (Part 2 of 2] 



Hex. 



Field 



Byte 


Name 


>2C 


VDTEUF 


>2E 


VDTFIL 


>2F 


VDTEVT 


>30 


VDTPOS 



Descriptio n 

The extended user flags to be used during the 
current operation. 

The fill character to be used during the 
current operation. 

The event character to be returned to the user 
call block. 

The current position of the cursor. 
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Hex. 

Byte 



Field 

Name 



Description 



>32 
>34 



>36 



VDTDEF 
VDTRED 



VDTSC1 



The beginning of the field. 

The buffer or address of the buffer for the 

read to address based on the flag in VDTSC1 

(see byte >36) . 

Flag word 1 as follows: 



Bit 


1 



3 
4 
5 
6 



7 

8 

9 

10 

11 

13 

14 
15 



Meaning 
Found beginning of Read Information 
Next start of header was requested 
by the DSR 

Read information goes into address 
in VDTRED (set to 1) ; otherwise 
stored in VDTRED 
Found first ESC in response 
Found a right parenthesis in string 
A second ESC was found in string 
An aid character was found. Aid 
characters are the SEND key and 
the 24 function keys. 
A change character set was found 
An attribute character was found 
The cursor position was found 
The requested read was finished 
Indicates terminal is in insert mode 
Indicates terminal is connected to 
the computer 

Indicates modem phone has rung 
Instructs DSR to set re-enter me flag 
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Hex. 
Byte 



Field 
Name ~ 



Description 



>38 



VDTSC2 



>3A 
>3C 
>3D 



Flag word 2 as follows: 

Bit Me aning 

Timed out~3evice 

1 Time out for response 

2 Printer has control of line 

3 Printer wants control of line 

4 EVT has control of channel 

5 EVT wants control of channel 

6 Extended character is in SCI 

7 Extended character is in SC2 

8 Alternate character set is in terminal 

9 Alternate character set is on input 

10 Alternate character set is on read 
to address 

11 Graphics set is in terminal 

12 Graphics set is on input 

13 Graphics is set on read to address 

14 Terminal busy flag 

15 A mode 3 table check is in progress 



VDTSC3 Link register save location 

Reserved 
GENSPD Tetminal definition as follows; 



Bit Meaning 

Set if switched 

3-7 Speed of terminal 



Setting 
11110 

10101 
10001 

11111 

11011 
10111 
10 011 



Speed 

110 baud 

300 baud 

600 baud 

1200 baud 

2400 baud 

48 00 baud 

9600 baud 



>3E 



Reserved 
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Hex. Field 

Byte Name Description 

>40 VDTATT Attribute sent to terminal as follows: 

Bit Meaning 

2 Double wide characters 

3 Nondi splay 

4 Blink display 

5 Underline display character 

6 Reverse image display character 

7 High intensity display character 

>41 VDTATB Attribute received from terminal bit 

definition the same as VDTATT 

>42 VDTSC4 Link register save location for outputting 

characters 

>44 VDTCNT Counter for VDTRED 

>46 VDTPTR Pointer to attached printer, if present 

>48 VDTSC5 Link register for saving character sets 

>4A vdtmfl Flag word for mode flags 

Bit Meaning 

Pass through flag 

1* Terminate on receipt of ETX 

2* Terminate on receipt of ESC 
right parenthesis 

3 Extended event characters 

4 Extended display characters 
5** Allow ESC and SOH through 

write ASCII 
6** Do not set attributes 
7** 132-column mode 3 flag 

8 Modified data to caller 

9 Extended caller validation 
10-15 Reserved 



Notes: 

* Flag applies only if bit of VDTMFL is on. 

** Flag applies only if bit 3 or bit 4 of VDTMFL is on. 
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Hex. 
Byte 

>4C 



Field 

Name 



VDTEDL 



>4E 
>50 
>52 
>54 
>56 
>58 
>5A 
>5C 



VDTSIZ 
VDTFIS 
VDTSC6 
FIFOCT 
FIFOIP 
FIFOOP 
FIFOEP 
FIFOBP 



Description 
Flag word for event key flags as follows: 

Bit ** Meaning 

Erase field 

1 Right field 

2 Cursor left out of field 

3 Tab 

4 Reserved 

5 Skip 

6 Home 

7 Return 

8 Erase input 

9 Reserved 

10 Delete character 

11 Insert character 

12 Cursor right out of field 

13 Enter 

14 Left field 

15 Reserved 

Number of characters of screen memory 

Save R0 for FIFO 

Temporary storage 

FIFO count 

FIFO input pointer 

FIFO output pointer 

FIFO end pointer 

Beginning of FIFO 



FIFOPT FIFO length (beginning address of FIFO and 
length of FIFO set at system generation 



NOTE 

* Flag applies only if bit of VDTMFL is on. 

** Flag applies only if bit 3 or bit 4 of VDTMFL is on. 
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6.3.4.3 KSR Extension (KSR) . The KSR is an extension to the KSB 
used by keyboard-type devices such as the 733. The offsets are 
expressed from the beginning of the Physical Device Table (PDT) 
to which the KSB has been appended. Figure 6-9 shows the format 
of the KSR extension. 



Hex. 

Byte 
— * * 

>2C j KSRABT — ABORT ROUTINE ADDRESS j 

+ . f 

>2E | KSRCRD — CARRIAGE RETURN DELAY COUNT | 
+ . + 

>30 | KSRICD — INTER- CHARACTER DELAY COUNT j 

+ + 

>32 | KSRSSC — CASSETTE STATUS | 

+ + 

>34 I KSRACP — ACTIVE PDT ADDRESS | 

; + 

>36 | KSRQP1 — FIRST QUEUED PDT ADDRESS | 
+ f 

>38 | KSRQP2 — SECOND QUEUED PDT ADDRESS 1 
+ + 

>3A j KSRXUF — EXTENDED USER FLAGS | 

+ + f 

>3C | KSRFLG — GENERAL FLAGS | KSRSCH — SAVED CHAR | 
+ + + 

>3E | KSRTMO — TIMEOUT COUNT j 

* * 

>40 * 



Figure 6-9 KSR Extension to KSB 
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Hex. 
Byte 

>2C 

>2E 

>30 

>32 

>34 

>36 

>38 

>3A 

>3C 



Field 
Name " 

KSRABT 

KSRCRD 

KSRICD 

KSRSSC 

KSRACP 

KSRQP1 

KSRQP2 

KSRXUF 

KSRFLG 



>3D KSRSCH 
>3E KSRTMO 

>40 * 



Descr i ption 
The address of the abort routine. 
The carriage return delay count. 
The inter-character delay count. 
The status of the cassettes. 
The address of the active PDT for the 733. 
The address of the first queued PDT. 
The address of the second queued PDT. 
Extended user flags. 
General flags as follows: 



Bit 

1 
2 
3 
4 
5 



Meaning When Set 
Hang up condition. 
Time out switch. 
SCI is active during hang up. 
A data carrier droD was detected. 
Shift in/out for JISCII. 
Direct character input requested. 



Character saved for JISCII output. 
Timeout count for hang condition. 
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6.3.4.4 820 Extension (T82) . T82 is an extension of the KSB for 
the 820 terminal. The offsets are expressed from the beginning 
of the Physical Device Table (PDT) to which the KSB has been 
appended. Some fields must be compatible with the KSR because 
they are used outside of the Device Service Routine (DSR) . 
Figure 6-10 shows the format of the 820 extension. 

Hex. 



Byte 

* . 

>2C j T82PRB — SYSTEM FLAGS AND USER FLAGS 

+ 

>2E | 

T82EXT — EXTENDED PRB FLAGS 



+ + 

>3C | T82FLG — GENERAL FLAGS | 

+ + 

>3E | T82TMO — TIMEOUT COUNT | 

* , * 

>40 * 

Figure 6-10 820 Extension to KSB 
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Hex. 
Byte 

>2C 

>2E 
>3C 



Field 
Name 



T82PRB 



T82EXT 



T82FLG 



>3E 
>40 



T82TMO 
* 



Description 

System and user flags to be used during the 
current operation. 

Flags from the extended Physical Record Block 
(PRB) ; if not extended. 

General flags as follows: 

Bit Meaning When Set 

Hang up condition. 

1 Time out switch. 

2 SCI is active during hang up. 

3 A data carrier drop was detected. 

4 Shift in/out for JISCII. 

5 Direct character input requested. 

The timeout count. 



6.3.4.5 Character Queue. The character queue follows the 
and KSB extension for terminal devices. Currently, the char, 
queue starts at >64 from the beginning of the KSB. Howevei 
references to the queue should be through the KSB pointers. The 
length of the queue is set at sysgen time. The word following 
the queue buffer is the length of the queue. 



the >pE 
taraa 
;r, 1*1,1 
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6.3.5 Line Printer Extension (LPD) 

The line printer extension to the PDT is used for both fast 
(2230/2260, LP300/LP600) and slow (810/840) line printers. 
Figure 6-11 shows the format. 



Hex. 
Byte 



>00 i LPDDMF — PRINTER TYPE j 

+ + 

>02 1 LPDCC — CHARACTER COUNT | 

+ + 

>04 | LPDOUT — NEXT OUTPUT CHARACTER ADDRESS j 
+ + 

>06 | LPD IN — NEXT INPUT BYTE | 

+ + 

>08 | LPDMXC — MAXIMUM CHARACTERS \ 

+ . + 

>0A | LPDENR — END RECORD FLAG ] 

+__ + 

>0C | i 

LPDBUF — CHARACTER BUFFER 
(170 BYTES) 



>B6 * 



.* 



Figure 6-11 Line Printer Extension 

Hex. Field 

Byte Name Descriptio n 

>00 LPDDMF Describes the type of line printer. A zero 

denotes a fast printer and a 2 denotes a slow 
printer. 

>02 LPDCC The number of characters currently in the 

buffer. 

>04 LPDOUT A pointer to the next character to be output 

(unless LPDCC = 0) . 

>06 LPDIN A pointer to the next free byte in which a 

character can be stored (unless LPDCC = 
LPDMAX) . 

>08 LPDMXC The maximum number of characters that may be 

stored in the buffer. 
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Hex. Field 

B y fce Name Descripti on 

>0A LPDENR used as a flag to cause end record processing. 

>0C LPDBUF The 170-byte character buffer. 

>B6 * 

6.3.6 Tape Extension (TPD) 

The tape extension to the PDT is similar to the disk extension. 
Currently, the disk and tape are the only TILINE devices. 
Certain fields in these extensions that are used outside the 
Device Service Routine (DSR) must be in the same location. 
Therefore, the tape extension must be the same size as the disk 
extension. Figure 6-12 shows the format of the TPD. 

Hex. 
Byte 

* * 

>10 i TPDSVS — DEVICE STATUS I 

+ ; j 

>12 I TPDMAJ — MAJOR RETRIES COUNT 

+ 1 

>14 I TPDMIN — MINOR RETRIES COUNT | 

>16 J | 

>18 J | 

>1A j t 

TPDTIL — CONTROLLER IMAGE 

i i 

Figure 6-12 Tape Extension 

Hex. Field 

B Y te Name Description 

>10 TPDSVS The device status for a device characteristics 

call. 

>12 TPDMAJ A count of the number of major retries left. 

>14 TPDMIN A count of the number of minor retries left. 

>1A TPDTIL The controller image created to start an 

operation. 
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6.3.7 Floppy Diskette Extension (FPD) 

The floppy diskette PDT extension is used for CRU-type floppy 
diskettes (FD800) . TILINE floppy diskettes (FD1000) use the 
normal disk PDT extension. Figure 6-13 shows the format of an 
FPD. 



Hex. 



Byte 



* * 

>00 | FPDBAS ~ NOT USED | 

+ + 

>02 | FPDDNO — DISK DRIVE NUMBER | 

H + 

>04 ] FPDCMD — CONTROLLER COMMAND | 

+ + 

>06 i FPDLSC — CURRENT LOGICAL SECTOR NUMBER j 
+ + 

>08 | FPDCTK — CURRENT TRACK POSITION \ 

+ + 

>0A | FPDTRK — REQUESTED TRACK POSITION j 

+ + 

>0C | FPDSCT — REQUESTED SECTOR POSITION | 
+ '■ + 

>0E | FPDDBA — DATA BUFFER ADDRESS | 

+ + 

>10 j FPDDBL — DATA BUFFER LENGTH j 

+ + 

>12 | FPDDBR — REMAINING CHARACTER COUNT | 

+ . + 

>14 | FPDVCT — SAVED VECTOR ENTRY POINT | 

+ + 

>16 | FPDUSE ~ USE FLAG | 

* . * 

>18 * 



Figure 6-13 Floppy Diskette PDT Extension 
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Hex. 
Byte 

>00 

>02 

>04 

>06 
>08 
>0A 
>0C 

>0E 
>10 
>12 

>14 

>16 

>18 



Field 
Name 

FPDBAS 

FPDDNO 

FPDCMD 

FPDLSC 
FPDCTK 
FPDTRK 
FPDSCT 

FPDDBA 
FPDDBL 
FPDDBR 

FPDVCT 

FPDUSE 



Description 



Not used. 



The disk drive number is contained in bits 4 
and 5 of this word. 

The command that is to be issued to the disk 
controller. 

The current logical sector number. 

The current track position. 

The requested track position. 

The requested sector position within the 
track. 

The data buffer address. 

The data buffer length. 

The remaining character count for multi-sector 
transfers. 



i 



The saved vector entry point within the devic 
service routine (DSR) . 



Used as a flag to indicate that this PDT has 
control of the disk controller. 



6-36 



939153-9701 



System Design Document 



Data Structures 



6.4 PARTIAL BIT MAP (PBM) 



DX10 uses partial bit maps (PBMs) to find blocks of free ADUs on 
a disk. The system scans a disk, bringing in each PBM one at a 
time to check for the available ADUs represented in that PBM. 
Figure 6-14 shows the format of a PBM as it appears in memory, 
(not on the disk) . 



Hex. 

Byte 

>00 
>02 

>04 
>06 
>08 



>10C 



* * 

JPBMMAX - TOTAL # OF PBMS | PBMNUM - # OF PBM IN MEM| 
+ . + + 

| PBMFAU - FIRST AVAILABLE ADU ON THE DISK | 
+ . + 

1 PBMLRC - LRC CHARACTER OF PBM IN MEMORY j 
+ _ +-+ 

PBMLCB - OFFSET OF LARGEST CONTIGUOUS BLOCK | 
+ + 




AREA 
STORED 
+- ON 
DISK 



+ +_+ 

>106 j PBMBIG — SIZE OF LARGEST BLOCK OF FREE ADUS 

+ _ + 

>108 | PBMBGN — # OF ADUS FREE AT BEGINNING OF PBM | 
+ + 

>10A I PBMEND — f OF ADUS FREE AT END OF PBM I 



+ + 



PBMBIG, PBMBGN, AND PBMEND 
(REPEATED FOR EACH PBM ON THE DISK) 



* : * 



Figure 6-14 Partial Bit Map 
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Hex. 



Field 



Byte 


Name 


>00 


PBMMAX 


>01 


PBMNUM 


>02 


PBMFAU 


>04 


PBMLRC 


>06 


PBMLCB 


>08 




>106 


PBMBIG 



>108 



>10A 



PBMBGN 



PBMEND 



Descr ipt ion 

This is the total number of PBMs on the disk. 

The number of the PBM currently in memory 
(system table area.) 

The first available ADU on the disk. 

The longitudinal redundancy character (LRC) 
for the PBM currently in memory. 

The offset in ADUs to the largest contiguous 
block of free ADUs, relative to the current 
memory resident PBM. 

Starting at this address in the PBM are 254 
bytes that represent the actual bit map. 

Size in ADUs of the largest contiguous block 
of free ADUs for the corresponding PBM. Each 
PBM repeats the last three fields of the 
figure. 

Number of free ADUs at the very beginning of 
the corresponding PBM. Each PBM repeats thf 
last three fields of the figure. " 1 

Number of free ADUs at the very end of the 
corresponding PBM. Each PBM repeats the last 
three fields of the figure. 
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6.5 FILE CONTROL BLOCK (FCB) 

Within DX10 , files are represented by, or accessed through, file 
control blocks. As described in Section 1, whenever a file is 
accessed, a tree structure of FCBs is built into memory. This 
structure resembles the directory/file hierarchy on the disk. 
FCBs are built in the system table area by the File Utility 
Assign LUNO processor, and are basically a memory resident copy 
of the file descriptor record (FDR) of the file. Figure 6-15 
shows the format of a file control block. 

Hex. 
Byte 



>00 



>02 | 



FCBLEN — LENGTH OF FCB 
FCBRNM — RECORD NUMBER OF FDR 



>04 



>0C 



>10 



FCBFNM — FILE NAME 



FCBPSW ~ PASSCODE 



FCBFLG — FLAGS j 

+ , + + 

>12 I FCBCLA — LUNOs COUNT I FCBCDF — DESCEND. CNT I 



>14 



>16 



>18 



>1A 



>1C 



>1E 



>20 



>22 



FCBAFD — FCB ADDRESS OF FIRST DESCENDANT 
FCBALS — FCB ADDRESS OF LAST SIBLING 



FCBANS — FCB ADDRESS OF NEXT SIBLING 
FCBAPF — FCB ADDRESS OF PARENT 



FCBPRS — PHYSICAL RECORD SIZE 
FCBLRS — LOGICAL RECORD SIZE 



FCBPAS — PRIMARY ALLOCATION SIZE IN ADU 
FCBPAA ~ PRIMARY ALLOCATION ADDRESS 



Figure 6-15 File Control Block (FCB) (Part 1 of 2) 
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Hex. 

Byte 

+ + 

>24 I FCBSAS — SECONDARY ALLOCATION SIZE 1 
+ + 

>26 I FCBSAA — ADDRESS OF SAT BLOCK | 

+ _ + 

>28 I FCBEOM ~ END OF MEDIUM LOGICAL RECORD NUMBER | 
+ , + 

>2C | FCBBKM — END OF MEDIUM BLOCK NUMBER I 
+ _ + 

>30 I FCBOFM — END OF MEDIUM OFFSET I 

| 1 

>32 | FCBLRL — LOCKED RECORD LIST HEAD | 

+ + 

>3 4 I FCBLLH — LDT LIST HEAD I 

+ + + 

>36 J FCBAPB ~ UNITS/BLOCK ] FCBBPA — BLOCKS/UNIT | 
+ _ + ,___ + 

>38 | FCBPDT — DISK PDT ADDRESS ] 

+ + 

>3A I FCBEXT — BLOCK COUNT FOR FILE EXTENSION | 
+ + + 

>3E IFCBXCT — FILE EXT CNT | FCBMFG — MODIFIED FLGS | 
+ + + 

>40 | FCBRLA — REQUEST LIST ANCHOR | 

+ + 

>42 | FCBLST — POINTER TO LAST ENTRY ON REQUEST LIST I 

* ; __| 

>44 * 

Figure 6-15 File Control Block (FCB) (Part 2 of 2) 



Hex. 
Byte 



>00 



>02 

>04 
>0C 



Field 
Name 



FCBLEN 



FCBRNM 

FCBFNM 
FCBPSW 



Descriptio n 

Length in bytes of the FCB and any extensions 
(described later in this section). If there 
are no extensions, the value of this field is 
zero. 

The number of the directory file record that 
contains the file descriptor record for this 
file. 

File name (eight characters) 

Passcode, reserved for future extension. 
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Hex. 

Byte 



Field 

Name 



Description 



>10 FCBFLG Flags, which are the same as in a file 

descriptor record except for bits 12-13. The 
flags have the following meanings: 

Bit Meaning 

0-1 File usage flags: 

00 No special usage 

01 Directory 

10 Program file 

11 Image file 

2-3 Data format: 

00 Binary 

01 Blank Suppressed 

10 Reserved for ASCII & print forms control 

11 Reserved 



4 Allocation type: 

Bounded 

1 Unbounded 

5-6 File type: 

00 Reserved for device 

01 Sequential 

10 Relative record 

11 Key indexed 



Write protection flag: 

Not write protected 

1 Write protected 

Delete protection: 

Not delete protected 

1 Delete protected (file 

Temporary file flag: 

Permanent file 

1 Temporary file 



cannot be deleted) 
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Hex. 
Byte 

>10 



Field 
Name 



FCBFLG 



>12 
>13 

>14 
>16 



FCBCLA 
FCBCDF 



FCBAFD 



FCBALS 



>1A 


FCBAPF 


>1C 


FCBPRS 


>1E 


FCBLRS 


>20 


FCBPAS 


>22 


FCBPAA 


>24 


FCBSAS 



Des cri ption 
Flags, which are the same as in a file 
Bit Mean ing 

10 Blocked file flag: 

Blocked 

1 Unblocked 

11 Alias flag: 

Not an alias 

1 An alias file name 

12-13 Most restrictive access applied to all 
users of the file: 

00 Exclusive write 

01 Exclusive all 

10 Shared 

11 Read only 

14-15 Reserved 

Number of LUNOs assigned to the file. 

Number of descendant FCBs in memory. Only 
directory file may have descendants* 
Descendants are all files that are cataloged 
under this directory and any sub-directories. 

Address of the FCB of the first descendant 
(that is, the first file cataloged under this 
directory that was accessed, and is still 
being accessed) . 

Sibling pointers. All FCBs of files cataloged 
under the same directory are laterally linked 
by these pointers, as described in Section 1. 

Address of the FCB of the directory under 
which this file is cataloged. 

Size in bytes of a physical record of this 
file. 

Size in bytes of a logical record. 

Size in allocable disk units of the primarv 
file allocation. 

Starting ADU number of the primary allocation. 

Size in ADUs of the secondary allocation. 
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Hex. 
Byte 



>26 



>28 

>2C 
>30 
>32 

>34 



Field 

Name 



FCBSAA 



FCBEOM 

FCBBKM 
FCBOFM 
FCBLRL 



FCBLLH 



>36 


FCBAPB 


>37 


FCBPBA 


>38 


FCBPDT 


>3A 


FCBEXT 


>3E 


FCBXCT 


>3F 


FCBMFG 



Des c ript ion 

Address of the in-memory copy of the secondary 
allocation table (SAT) for the file. The SAT 
is an exact copy of the last 64 bytes of the 
file descriptor record (FDR) and is located in 
the system table area. 

The number of the logical record immediately 
following the last allocated logical record 
(end of medium) . 

The physical record in which the file 
allocation ends (end of medium) . 

The sector offset into the physical record 
that marks the end of medium. 

The head of a singly linked list of record 

lock tables, which are also located in the 

system table area, each of which points to a 
locked record of the file. 

Head of a linked list of all logical device 
tables that represent LUNOs assigned to this 
file. 

The number of ADUs per physical record. 

The number of physical records per ADU. 

The address of the PDT for the disk on which 
this file is written. 

Block count for file extension. 

Number of secondary allocations. 

Flags as follows: 

3it Meaning When Set 

End of medium for this file has changed 

1 Data has been written into the file 

2 FCB is busv 
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Hex. Field 

Byte Name Descri ption 

>40 FCBRLA Pointer to the next buffered I/O request for 

this file (I/O requests for the same file are 
queued from the FCB until processed by file 
management) . 

>42 FCBLST Pointer to the last buffered I/O request on 

the list for this file. 

>44 * 
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6.5.1 KIF Extension to the FCB 

When an FCB represents a key indexed file, an extension to the 
FCB is used to contain additional information. Figure 6-16 shows 
the format of a KIF extension. 

Hex. 



>00 


>04 


>06 


>08 


>0C 


>0E 


>10 


>12 


>14 


>16 


>18 



+- 

I 

+- 

I 

+- 



FCBTNB — TOTAL NUMBER OF BUCKETS 

FCBCMD — COMMAND NUMBER 
FCBCLB — CURRENT LOG BLOCK NUMBER 
FCBFBQ — FREE BLOCK QUEUE HEAD 



+- 

I 

I 
+- 

+- 

I 

+- 

I 
+- 

I 

+- 



FCBBTR — B-TREE ROOTS BLOCK NUMBER 
FCBSBB — BLOCK NUMBER OF FIRST BUCKET 
FCBMRS — MINIMUM LOGICAL RECORD SIZE 



-+ 

-+ 

I 
-+ 

-+ 
-+ 

! 

I 

-+ 

! 

•+ 



FCBKDB — NUMBER OF KEYS 
+ 

FLAGS | CHARACTER COUNT OF KEY 1| 
+ + 

OFFSET TO KEY 1 J 
+ 



*- 
>4C * 



Figure 6-16 FCB Extension for Key Indexed Files 



NOTE 

Repeat bytes 14 through 17 for secondary 
keys. 
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Hex. 

Byte 

>00 
>04 

>06 

>08 

>0C 
>0E 
>10 
>12 

>4C 



Field 
Name 

FCBTNB 

FCBCMD 

FCBCLB 



FCBFBQ 



FCBBTR 



FCBSBB 



FCBMRS 



FCBKDB 



Description 

Total number of buckets allocated in the file. 

The opcode of the current command (used for 
logging) . 

The physical record number of the currently 
used log block (see the discussion on key 
indexed files in Section 4) . 

The physical record number (block number) of 
the first record in a linked list of available 
records. 

The number of the first physical record 
containing a B-tree root. 

The number of the first physical record 
containing the first bucket. 

Minimum logical record size, in bytes, needed 
to contain all defined keys. 



These fields are in-memory duplicates of bvte 
6-63 (>06->3F) of the disk resident "k 
descr iptor recor d . 



^ 



6.5.2 Queue Extension to the FCB 

When the file represented by an FCB is a directory, a queue 
anchor of the form shown in Figure 6-1 is appended to the FCB. 
The queue anchored is a queue of TSBs of tasks waiting for access 
to the directory file. The queue is implemented to prevent both 
file management and file utility from updating the same directory 
record concurrently; (for example, if one task was writing to a 
file and another task was renaming the file at the same time). 
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Hex. 

Byte 

>00 

>02 

>04 

>06 
>07 
>08 
>09 



Field 

Name 



FCBQUE 



FCBLOK 



FCBQFL 



FCBQST 



Description 

Address of the TSB of the newest task waiting 
for access. 

TSB address of the oldest task waiting for 
access. 

TSB address of the task currently accessing 
the directory. 

Flags. Must have a value of >4 0. 

Task Id of server. Must be zero. 

Task state. Must be >1E. 

Count of items on queue. 



6.5.3 Record Lock Table (RLT) 

An RLT is a IQ-byte block of system table area that points to a 
file record that is locked. All locked records of a file are 
represented by a linked list of RLTs, ordered by an ascending 
disk address, which is headed by a word in the file control 
block. Each time a record is locked, file management builds a 
new RLT and links it on the list. Figure 6-17 shows the format 
of a record lock table. 



Hex. 
Byte 

>00 

>02 

>04 

4. 

>08 

* 

>0A * 



RLTLNK — TABLE LINK 
RLTLDT — LDT ADDRESS 




RLTOFF — OFFSET IN BLOCK 



Figure 6-17 Record Lock Table (RLT) 
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Hex. Field 

B y fce Name" . Description 

>00 RLTLNK Link to the next RLT (0 = end of list). 

>02 RLTLDT Address of the logical device table that 

represents the LUNO assigned by the task that 
locked this record. 

>04 RLTBLK Number of the physical record of the file in 

which the locked logical record is written. 

>08->09 RLTOFF The logical record within the above addressed 

physical record that is locked. 



6.5.4 Program File Extension to the FCB 

When an FCB represents a program file, an extension to the FCB is 
used to contain additional information. Figure 6-18 shows the 
format of the program file extension. 



Hex. 
Byte 



* L mt 



+ 



>00 j FCBMNT — MAX NO TASKS J FCBTO — DIR OFFSET 

"^ — ——————— ————————— _______ +—____ _____ _____ ________ __j. 

>02 | FCBTR —TASK DIRECTORY ENTRY RECORD NUMBER I 

+ + 

>04 | FCBMNP — MAX NO PROCS | FCBPO — DIR OFFSET 

+ + 

>06 | FCBPR — PROCS DIRECTORY ENTRY RECORD NUMBER 

+ ___+ 

>08 | FCBMNO — MAX NO OVLYS | FCBOO — DIR OFFSET 

+ + 

>0A | FCBOR — OVERLAYS DIRECTORY ENTRY RECORD NUMBER 

*————————_—_________ 

>0C * — — — — _—_______. 



Figure 6-18 FCB Extension for Program Files 
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Hex. 



Field 



Byte 


Name 


>00 


FCBMNT 


>01 


FCBTO 


>02 


FCBTR 


>04 


FCBMNP 


>0 5 


FCBPO 


>06 


FCBPR 


>08 


FCBMNO 


>09 


FCBOO 


>0A 


FCBOR 


>0C 


* 



TDescription 

Maximum number of task entries in the file. 

Task directory entry offset. 

Task directory entry record number. 

Maximum number of procedure entries in the 
file. 

Procedure directory entry offset. 

Procedure directory entry record number. 

Maximum number of overlay entries in the file. 

Overlay directory entry offset. 

Overlay directory entry record number. 
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6.6 LOGICAL DEVICE TABLE (LDT) 

Logical^ device tables are built in the system table area by the 
file utility assign LUNO processor. Whenever a LUNO is assigned 
to a file or device, an LDT is built to represent the logical 
unit to the system. Figure 6-19 shows the format of an LDT. 



Hex. 



Byte 
>00 
>02 
>04 
>06 
>08 
>0A 
>0C 
>0E 

>12 

>16 
>18 
>1A 
>1C 



LDTPDT — PDT ADDRESS 



LDTLUN — LUNO 



LDT IOC — START I/O CNTJ 



LDTFLG — FLAGS 
LDTLDT — LDT LINK 



LDTTSB — USER TSB ADDRESS 



LDTFLL — FILE LINK 



LDTFCB — FCB ADDRESS 



LDTLRN ~ CURRENT LOGICAL RECORD NUMBER 



LDTBN — CURRENT BLOCK NUMBER 



+- 
+- 



LDTOCB — OFFSET IN CURRENT BLOCK 
LDTBLK — BUFFER BEET ADDRESS 



LDTORC— OUTSTANDING REQS | LDTNU — NOT USED 



Figure 6-19 Logical Device Table (LDT) 



NOTE 

Bytes >00->09 are the same for file and 
device LDTs. Bytes >10->1B are used only for 
file LDTs. 



-+ 

! 

-+ 

I 
-+ 
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Hex. 

Byte 

>00 



>02 
>03 

>04 



>06 
>08 



Field 

Name 



LDTPDT 



LDTLUN 
LDTIOC 

LDTFLG 



LDTLDT 



LDTTSB 



Description 

Address of the PDT to which the LUNO is 
assigned. For LUNOs assigned to files, this 
is the PDT for the disk unit on which the file 
is written. 

The LUNO which this LDT represents. 

The number of initiate I/O operations 
currently being performed at this LUNO. 

Flags as follows: 

Bit Meaning When Set 

This LDT is used to anchor a list of LDTs 
(such as in a KSB) . 

1-2 Access privileges: 

00 Exclusive write 

01 Exclusive all 

10 Shared 

11 Read only 

3 The file to which the LUNO is assigned was 
created by the Assign LUNO SVC. 

4-5 Scope of LDT anchor 

(that is, what kind of LUNO) : 

00 Task local 

01 Station local 

10 Global 

11 Undefined 

6 Deferred write error. 

7 File is forced write. 

8 LUNO is a system LUNO (cannot be released) 

9 LUNO assigned to a file. 

10 LUNO is busy. 

11 Event mode is locked in record mode. 

12 Initiate I/O is being performed. 

13 Abort I/O is being performed. 

14 Unblocked access. 

15 Print flag. 



Link to the next LDT in the LDT inverted 
structure described in Section 1. 



tree 



TSB address of the task that opened the LUNO. 
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NOTE 

The remaining fields (bytes >0A through >1B) 
are only defined for LDTs that represent 
LUNOs assigned to files. When a LUNO is 
released, or the task that assigned the LUNO 
terminates, the LDT is released by the file 
utility Release LUNO routine. 



>0A 



>1A 

>1B 
>1C 



Field 
Name 



LDTFLL 



>oc 


LDTFCB 


>0E 


LDTLRN 


>12 


LDTBN 


>16 


LDTOCB 


>18 


LDTBLK 



LDTORC 



LDTNU 



Descript ion 

Link to the next LDT representing a LUNO 
assigned to the same file. All LDTs assigned 
to the same file are linked together, and 
anchored in the file control block. 

Address of the file control block for the file 
to which the LUNO is assigned. 



The number of the logical record that 
currently being accessed. 



is 



The number of the physical record that i| 
currently being accessed. 

The offset into the physical record to the 
current logical record. 

The beet address of the buffer that contains 
the last physical record transferred (read or 
written) through this LUNO (zero if the buffer 
has been released) . 

Number of outstanding requests for I/O to this 
LUNO. 

Not used. 



6.7 BUFFERED CALL BLOCK 

Whenever a supervisor call that is processed by a queue serving 
routine is issued, the call block is buffered in the system table 
area and queued for the SVC processing routine. The first four 
words of the buffer contain the following system overhead. 
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Byte 


Field 

Name 


>00 




>02 




>04 




>06 
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Des cri ption 

Link to the next entry in the queue. 

Address of the TSB of the task issuing the 

SVC. 

Address of the call block within the calling 

task. 

Address of the LDT to which an I/O operation 

is directed (used only for I/O SVCs) . 

The remainder of the buffer contains the call block and any 
extension blocks or data buffers. 



6.8 TASK STATUS BLOCK (TSB) 

Tasks are represented within DX10 by a task status block (TSB) . 
TSBs are built in the system table area by the bidding routines 
TMBIDO and TM$BID. A TSB is released by the termination task, 
TMDGN, when a task terminates, unless the task is a queue server. 
TSBs of inactive queue servers are not released unless more 
system table area is needed. Figure 6-20 shows the format of a 
task status block. 



Hex. 
Byte 

* ; * 

>00 | TSBQL — QUEUEING LINK | 

+ + 

>02 | TSBWP — ACTIVE WP | 

>04 | TSBPC — ACTIVE PC | 

+ f 

>06 | TSBST ~ ACTIVE ST | 

+ . + + 

>08 | TSBPRI — PRIORITY | TSBSTA — TASK STATE | 
+ + + 

>0A j TSBFLG — TASK FLAGS | 

+ . + 

>0C 1 TSBEAC — TRANSFER VECTOR ADDRESS j 

+ + + 

>0E | TSBID — INSTALLED ID | TSBRID — RUN ID | 
+ + + 

>10 | TSBSMF — SAVED MAP FILE ADDRESS | 

+ + 

>12 | TSBLNK — FIXED TSB LINK | 

+ + 

Figure 6-20 Task Status Block (TSB) — Part 1 of 3 
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Hex. 
Byte 

>14 



>16 



>18 



>1A 



>1C 



>20 



>22 



>24 
>26 



>28 



>2A 



>2C 



>2E 



>32 



>34 
>36 



>38 



>3A 



>3C 



TSBKSB — KSB ADDRESS 
TSBFL2 — mSK FLAGS (WD2) 



TSBAR1 — BID PARAMETER (1) 
TSBAR2 — BID PARAMETER (2) 



TSBALT — ALTERNATE TSB ADDRESS ! 

+ + + 

>1E | TSBCHR — 913/911 CHAR ITSBIOC — TILINE I/O CNTI 



TSBPR1 — PSB ADDRESS (PROC 1) 
TSBPR2 -- PSB ADDRESS (PROC 2) 



TSBFCB — PROGRAM FILE TCB ADDRESS 
TSBERC — DIAGNOSTIC ERROR CODE 



TSBWPD — DIAGNOSTIC WP 
TSBPCD — DIAGNOSTIC PC 



TSBSTD — DIAGNOSTIC ST 



TSBTDl — TIME DELAY COUNTER 
TSBTD2 



TSBML1 — MAP LIMIT 1 



TSBMB1 ~ MAP BIAS 1 
TSBML2 ~ MAP LIMIT 2 



TSBMB2 — MAP BIAS 2 
TSBML3 — MAP LIMIT 3 



TSBMB3 — MAP BIAS 3 | 

+ + + 

>3E |TSBPRF — FIXED PRIORITYl TSBMRG — TASK REG NO | 

+ f __ + 

Figure 6-20 Task Status Block (TSB) — Part 2 of 3 
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Hex. 



Byte 



>40 I TSBPAR — PARENT TSB ADDRESS 

+ 

>42 | TSBSON — OLDEST SON TSB ADDRESS 

+ . 

>44 i TSBBR1 — OLDER SIBLING TSB ADDRESS 

+ 

>46 | TSBBR2 — YOUNGER SIBLING TSB ADDRESS 

+ 

>48 | TSBBLN — BEET LENGTH OF PROGRAM 

+ 

>4A | TSBTON — OVERLAY NUMBER 

+ 

>4C | TSBOAD — ADDRESS OF OVERLAY AREA DES . 

+ 

>4E i TSBTO — TIME TASK SUSPENDED 

+ 

>50 j TSBT1 — NUMBER OF TIME SLICES REMAINING 

+ 

>52 I TSBSCR — SCRATCH FOR GETMEM 



>54 j TSBRLL — LINK TO NEXT ROLLED TASK j 

+ + 

>56 I TSBRRN — ROLL FILE STARTING PHYSICAL RECORD NO 

+ 

>5A | TSBRRL — NUMBER OF ROLL FILE RECORDS 

+ 

>5C | TSBLDF — LOCAL LDT LIST FLAGS 

+ , , , 

>5E I TSBLDA — LOCAL LDT LIST ADDRESS 



>60 I TSBEOR — EOR COUNT | TSB I IP — I/O COUNT | 
+ + + 

>62 j TSBSER — QUEUE ANCHOR ADDRESS \ 

+ + 

>64 | TSBTSC — TASK SENTRY COUNT | 

* . * 

>66 * 



Figure 6-20 Task Status Block (TSB) — Part 3 of 3 
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Hex. 



Field 



Byte 


Name 


>00 


TSBQL 


>02 


TSBWP , 




TSBPC, 



>08 

>09 
>0A 



TSBST 
TSBPRI 

TSBSTA 
TSBFLG 



Description 

Link to the next TSB on the queue, when this 
TSB is queued. 

The saved context (workspace pointer, program 

counter and status register values) for the 

task. 

When the task is scheduled to execute, these 

saved values are used to begin execution. 

Task priority (0, 1, 2, 3, or >81, >82, >83, 
>84, ..., >FF) where >81 is real-time 
priority 1 and >FF is real-time priority 127. 

Task state as shown in Table 6-1. 

First word of task flags. The flags are as 
follows: 

Bit Meaning When Set 

System task (Hardware and 
software privilege) 

1 Privileged task (Software) 

2 Memory resident task 

3 Take end action on error 

4 Roll out candidate 

5 Rolled out 

6 Abort/terminate task 

7 Activate call outstanding 

8 Reactivate bidding task at termination 

9 Serially reusable task 

10 Task quieting in progress 

11 Initial bid 

12 Leave task alone; do not abort 

13 Task is under control of alternate 
TSB 

14 SCI flag for scanning TSB chain 

15 Task is replicated image 

>0C TSBEAC Transfer vector address. 

>0E TSBIID Installed task ID. 

>0F TSBRID Runtime ID assigned by system. 

>10 TSBSMF Address in the TSB of the saved map file 

register values (bytes >32->3D) . 
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Hex. 
Byte 

>12 



Field 

Name 



TSBLNK 



>14 



>16 



TSBKSB 



TSBFL2 



>18 



>1C 



TSBAR1 



TSBALT 



Descrip t ion 

Link to the next TSB in the fixed list of 
TSBs. All TSBs in the system table area are 
linked onto this list when they are created. 
The list may be searched to find a task with a 
given runtime ID by the routine named TMTSCH 
(for example, to kill the task) . 

Address of the KSB of the terminal with which 
this task is associated (that is f the task was 
bid from the terminal) . 

Task flags as follows: 

Bit Meaning When Set 

Task to be suspended next time it 
executes 

1 Task is being controlled 

2 SVC traps to be taken when specified 

3 SVC switch: when 0, SVC traps are taken 

4 Execution stopped by scheduler 

5 Execution stopped by trapped SVC 

6 Execution stopped by XOP 15,15 
(breakpoint) 

7 Dynamic priority management 

8 Roll in progress 

9 Task activated 

10 Initiate followed by execute I/O 

11 Extend time slice 

12 End action available for task 
11-15 Not used 

The two parameters that mav be passed to the 
task by the Bid SVC, and accessed by the task 
using the Get Bid Parameters SVC. 



TSB address of 
alternate task 
task. 



the alternate task. The 

is executed in place of this 



>1E 


TSBCHR 


>1F 


TSB IOC 


>20 


TSBPR1 


>22 


TSBPR2 



913/911 character. 

Number of outstanding TILINE I/O operations. 

Address of the procedure status block (see 
paragraph 6.7.1) for attached procedure 1 (0 
if none) . 

PSB address for procedure 2 (0 if none) . 
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Hex. 
Byte 

>24 
>26 

>28 



>2E 

>32 

>3E 
>3F 

>40 
>42 
>44 
>46 
>48 
>4A 

>4C 



Field 
Name 

TSBFCB 



TSBERC 

TSBWPD, 
TSBPCD, 
TSBSTD 
TSBTD1 

TSBML1 

TSBPRF 
TSBMRG 

TSBPAR 
TSBSON 
TSBBR1 
TSBBR2 
TSBBLN 
TSBTON 

TSBOAD 



Descri ption 

Address of the FCB that represents the program 
file on which this task is installed. 

Error code that describes the error that 
caused the task to terminate (used by 
termination task) . 

The context (WP, PC, and ST registers) of the 
task at the time an error forced the task to 
terminate or take end action (used by the 
termination task) . These values are returned 
on a Get End Action Status SVC. 

Number of system time units remaining before 
this task will be reactivated from its time 
delayed state (32 bits.) 

The map register values to be used when this 
task executes. 

Map flags. Fixed priority of task. 

The offset into the saved map file that marks 
the limit register that maps the task segment 
(that is, 0, 4, or 8) . 

TSB family tree pointers as described in 
Section 1. 

TSB family tree pointers as described in 
Section 1. 

TSB family tree pointers as described in 
Section 1. 

TSB family tree pointers as described in 
Section 1. 

Length of the entire program (task and 
procedures) in beets (32-byte blocks) . 

The number of the system overlay in which this 
task was last executing (used for system tasks 
only) . 

The address of the overlay area in which the 
above overlay was loaded (the overlay MUST be 
reloaded in the same place) . 
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Hex. 
Byte 

>4E 
>50 



>52 



>54 



Fie ld 
Name 



TSBTO 



TSBT1 



TSBSCR 



TSBRLL 



>56 



TSBRRN 



>5A 



>5C 



>5E 



>60 



TSBRRL 



TSBLDF 



TSBLDA 



TSBEOR 



Descri ption 

Number of time slices this task has been 
suspended. 

Number of time slices still allotted to this 
task as the minimum number of time slices it 
must receive before it can be forcibly rolled- 
out by an equal priority task. 

Scratch used by the Get Memory SVC processor 
and the system overlay loader. 

Link to the TSB or PSB that represents the 
next rolled segment. The TSB or PSB of each 
rolled task or procedure is linked onto a list 
of rolled segments. The list is kept in order 
by increasing the roll file record number; 
that is, segments that were written at the 
beginning of the roll file are at the 
beginning of the list. This linked list 
serves as a directory into the roll file, s3 
that the various rolled segments can be 
retrieved for roll-in. Further roll 
information is kept in TSBs or PSBs. 

Number of the physical record in the roll file 

that begins the rolled image of the task 

segment. At initial bid time, this is the 
program file record number. 

Number of roll file records occupied by the 
rolled task image. During initial bid, this 
is the length of the task in bytes. 



Task local LDT list flags: 
anchor . 



bit is the LDT 



Pointer to the first task local LDT, or the 
station local LDT list anchor (if there are no 
task local LDTs) . 

Number of I/O end-of-records that need to be 
processed for this task. If this field is 
non-zero, the device driver routine (DDT) is 
given the next time slice that would otherwise 
have been awarded to this task. 



>61 



TSBIIP 



The number of I/O operations outstanding 
this task. 



for 
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Hex. Field 

Des crip t ion 

The address of the anchor for the queue served 
by this task (used only for queue servers) . 

The task sentry count. 



Byte 


Name 


>62 


TSBSER 


>64 


TSBTSC 


>66 


* 



Table 6-1 Task State Codes 



Task 

Stat e Sign ificance 

00 Active task, priority level 

01 Active task, priority level 1 

02 Active task, priority level 2 

03 Active task, priority level 3 

04 Terminated task 

5 Task in time delay 

06 Suspended task 

07 Currently executing task 

08 Reserved 

09 Task awaiting completion of I/O 

0A Task awaiting assignment of device for I/O 

0B Task awaiting disk file utility services 

0C Reserved 

0D Task awaiting file management services 

0E Task awaiting overlay loader services 

OF Task awaiting initial load 

10 Reserved 

11 Task awaiting disk management services 

12 Task awaiting tape management services 

13 Waiting on system overlay loader services 

14 Waiting on task driven SVC processor 

15 Task waiting on GETMEM request 

16 Not used 

17 Suspended for co-routine activation 

18 Task waiting on termination task services 

19 Task awaiting completion of any I/O 
1A Waiting on MM$FND door 

IB Task eligible for rollout when requested I/O 

is complete 

1C Task activated while roll in progress 

ID Suspended for initiate I/O threshold 

IE Suspended for locked directory 

IF Suspended for task management directory buffer 

24 Task suspended for queue input 

FF Dummy task state 



6-60 939153-9701 



System Design Document Data Structures 



5.9 PROCEDURE STATUS BLOCK (PSB) 

Each procedure being accessed by a task within DX10 is 
represented by a procedure status block, just as tasks are 
represented by TSBs. When a task is bid, the bidder task, 
TM$BID, checks to see if the task has any attached procedures. 
If so, the bidder task scans the fixed list of PSBs anchored in 
the D$DATA module to see if the procedures are already in memory. 
If not, TM$BID builds a PSB for the procedures. 

A PSB is built in the system table area and linked on the fixed 
list of PSBs. Figure 6-21 shows the format of a PSB. 

Hex. 
Byte 

* + * 

>00 i PSB ID — PROCEDURE ID j PSBFLG — FLAGS | 
+ + + 

>02 I PSB ADD — PROCEDURE ADDRESS | 

+ + 

>04 j PSBLEN — PROCEDURE LENGTH | 

+ + 

>06 | PSBLNK — FIXED PSB LINK | 

+ + 

>08 j PSBFCB — PROGRAM FILE FCB ADDRESS j 

+ + + 

>0A IPSBATT -- NO. ACT. TASKS | PSBTIM— NO. IN-MEM TASKS | 
+_ + + 

>0C | PSBRLL — LINK TO NEXT ROLLED SEGMENT j 

+ -■ . 

>0E | PSBRN1 — RELATIVE RECORD NUMBER IN ROLL 

+ 

>10 | PSBRN2 — FILE/PROGRAM FILE 

+ + 

>12 | PSBRRL — NUMBER OF ROLL FILE RECORDS 

* 

>14 * 

Figure 6-21 Procedure Status Block (PSB) 
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Hex. 
Byte 

>00 
>01 



>02 

>04 
>06 

>08 

>0A 

>0B 

>0C 

>0E 
>10 
>12 

>14 



Fiel d 
Name 



PSBID 



PSBFLG 



PSBADD 

PSBLEN 
PSBLNK 

PSBFCB 

PSB ATT 

PSBTIM 

PSBRLL 

PSBRN1 
PSBRN2 
PSBRRL 



Descrip tion 

ID assigned to the procedure when it was 
installed on the program file. 

Flags as follows: 

Bit Meaning When Set 

Memory resident "procedure 

1 This is the initial bid of the procedure 

2 Procedure is rolled out 

3 Procedure roll is in progress 

4 Writable control storage XOP 

5 PROC is write protected 

6 PROC is execute protected 

Address of the starting beet (32-byte block of 
memory) of the procedure. 

Length of the procedure in beets. 

Link to the next PSB in the fixed list of PSBs 
(zero if at end of list) . 



Address of the FCB for the program 
which the procedure is installed. 



file on 



Numbe r of ac t i ve 
procedure . 



tasks that share 



this 



Number of active tasks with memory 
rolled) that share this procedure. 



Link to the next rolled 
described for TSBs) . 



segmen t 



{not 
(same as 



Relative record number in roll. 

File/program file. 

Number of roll file records occupied by the 
rolled procedure. During the initial bid, 
this is the length of the procedure in bytes. 



A PSB may be released to the system table area by the memory 
management routine named RELPSB. The PSB may only be released if 
the procedure has zero attached active tasks, in which case both 
the procedure memory and the PSB are released. 
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6.10 TIME ORDERED LIST (TOL) 

As described in Section 1, all allocated blocks of memory 
(excluding the system table area) are linked on a doubly-linked, 
circular, time ordered list. This is done in order to support 
the least recently used algorithm used by DX10 memory management 
to select blocks of memory for rollout. 

Blocks of memory that may be on the TOL are: task memory, 
procedure memory, and file management blocking (I/O) buffers 
(maximum of 30 buffers on TOL) . Whenever a block of memory is 
accessed (that is, executed if it is a task; read or written if 
it is a buffer), it is removed from its current position on the 
TOL, and relinked at the beginning of the list when the access is 
ended. An exception to this rule is procedure memory, which is 
not removed from the TOL when procedures are used. Procedure 
blocks, therefore, tend to go to the end of the list. 

The overhead involved in maintaining the TOL consists of a TOL 
header, located in the D$DATA module, and an overhead beet (32- 
byte block) at the beginning of each allocated segment of memory. 
The overhead beet is created by either the task loader (for tasks 
and procedures) or buffer management (for blocking buffers) . 
Figure 6-22 shows the format of a TOL beet. Note that an 
overhead beet is also used to maintain the linked list of free 
memory blocks (see paragraph 6.11). 
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Hex. 
Byte 

>00 



>02 



>04 



>06 



>08 



>0A 



1 


TOLLEN — BLOCK LENGTH 


1 


TOLPTR — POINTER 


1 


TOLFLK — FORWARD LINK 


I 


TOLBLK — BACK LINK 


1 


TOLTYP — BLOCK TYPE 



NOT USED 



>18 



>1A 



>1C 



>20 






BUFFLG — FLAGS 



BUFRLN — BUFFER LENGTH 

+ , , 

BUFBLK — PHYSICAL RECORD NUMBER 
(USED ONLY FOR BUFFERS) 



_* 



Figure 6-22 TOL Overhead Beet 



Hex. 
Byte 


Field 
Name ~ 


>00 


TOLLEN 


>02 


TOLPTR 



>04 
>06 



TOLFLK 
TOLBLK 



Descrip tion 

Length, in beets, of the attached block of 
memory including this overhead beet. 

Pointer, which varies depending on how this 
block is being used: 

Task — Pointer to TSB 

Procedure — Pointer to PSB 

Buffer — Pointer to LDT 

Free block — Pointer to next free block 

Forward link to next oldest block. 

Back link to next youngest block. 
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Hex. 
Byte 

>08 



>0A 
>18 



Field 




Name 


Description 


TOLTYP 


Block type as follows: 



BUFFLG 



1 = 

2 = 

3 = 
= 

•1 = 



task 

procedure 
free block 
blocking buffer 
list header 



Not used. 

Flags as follows: 

Bit Mea ning When Set 

Buffer is~~5usy 

1 Write this block 

2 This is the memory resident buffer 

3 Release this buffer immediately 



>1A 
>1C 
>20 



BUFRLN Length of buffer (excluding overhead beet) in 
bytes. 

BUFBLK Number of the file physical record that is 
buffered in this buffer. 



6.11 SYSTEM LOG PARAMETER BLOCKS (SLPB) 

Whenever _ a message is to be written to the system log, the 
message information is queued to the system log message queue in 
the form of a 12-byte system log parameter block (SLPB) plus 
extensions. The SLPB is created by different routines depending 
upon the source of the log message as follows: 



Source 
Device Errors 

Task Errors 

User Messages 
Log Messages 
Memory Errors 



Creatio n Rout ine 

SYSLQ, called by DDTEND, the end record 
and statistic messages processor. 

SLPBQC, called by TM$DEN, the diagnostic 
task. 

SLSVC, the system log SVC processor. 

SLMFOT, the system log formatter. 

Non-correctable errors in TM$INT; 
correctable errors in TM$SHD. 
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The SLPBs are queued for the system log formatting and output! 

task, SLMFOT, which formats each SLPB and writes the message to 

the logging device and/or files. Figure 6-23 shows the format of 
the SLPB. 



Hex. 



Byte 

* , . ,_* 

>00 | SLPB — QUEUE LINK | 

+ + 

>02 I SLDAY — JULIAN DAY | 

+ + + 

>04 I SLHOUR — HOUR [ SLMIN — MINUTE | 
+ + + 

>06 ! SLFLAG — SLB FLAGS | SLXKEY — EXTENSION KEY | 
+ + + 

>08 I SLTYPE — ERROR TYPE I 

* * 

>0C * 

Figure 6-23 System Log Parameter Block 

Hex. Field 

Byte Name" Descri p tion 

>00 SLPB Link to the next block on the queue. 

>02 SLDAY Julian day. 

>04 SLHOUR Hour . 

>0 5 SLMIN Minute. 

>06 SLFLAG Flags as follows: 

Bit Meani ng When Set 

Subsequent messages have been lost 
1-7 Not used 
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Hex. 
Byte 



>07 



Field 
Name ~ 



SLXKEY 



Des cripti on 
Extension key as follows: 



Device extension with controller image 

1 User call extension 

2 Memory error extension 

3 Statistics extension 

4 Interrupt extension 
6 Task extension 

8 Cache memory extension 

9 Device extension with PRB 



>08 
>0C 



SLTYPE 
* 



Error type (task, DS01, and so on.) 



Depending upon the source of the message, various extension 
blocks are appended to the SLPB. The type of extension block to 
be appended is indicated by the extension key in the SLPB. The 
format of each of the extension blocks is shown in the following 
paragraphs. 
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6.11.1 Device Extension with Controller Image (SLXKEY = 0) 

Figure 6-24 shows the format of the 3LPB Device Extension with 
Controller Image. 

Hex. 
Byte 

* f * 

>0C | SLEC — DX10 ERROR CODE | SLINID — INSTALLED ID | 
+ + + 

>0E I SLRNID — RUNTIME ID | SLSTID — STATION ID | 
+ + __ + 

>10 | SLLUNO — LUNO ] SLRTRY — RETRIES | 
+ f + 

>12 ISLSORF— S=SUCCESS F=FAIL| NOT USED | 

+ f f 

>14 |SLACNT— # AFTER IMG WDS | SLBCNT— # BEFORE IMG WDS | 
+ . + + 

>16 | | 

AFTER IMAGE 



+ + 

>26 | | 

BEFORE IMAGE 



* * 

>3C * 

Figure 6-24 SLPB Device Extension With Controller 
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6.11.2 User Call Extension to SLPB (SLXKEY = 1) 

Figure 6-25 shows the format of the User Call Extension to the 
SLPB. 



Hex. 

Byte 



>0C ISLMLEN — MESSAGE LENGTH | USER MESSAGE BEGINS HERE 
+ + (255 BYTES MAX.) 



Figure 6-25 User Call Extension to SLPB 



6.11.3 Memory Error Extension to SLPB (SLXKEY = 2) 

The Memory Error Extension applies to 16K RAMs only. Figure 6-26 
shows the format of the Memory Error Extension to the SLPB. 



Hex. 
Byte 



>0C 



>0E 



>10 



SLBIT — BIT IN ERROR 
(0-15, 6 ECC bits) 



SLROW — ROW IN ERROR 



>12 I 
>14 * 



SLCORR — CORRECTABLE ISLBAS2 — CONTR BASE ADDR 
ERROR? (Y=yes, N=no) | 
+ . 

SLMEM2— AMOUNT OF MEMORY! SLTYP2 — CONTROLLER 
(Controller only) | TYPE 

+ 

SLADR2 — TPCS ADDRESS OF CONTROLLER 



Figure 6-26 Memory Error Extension to SLPB 
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6.11.4 Statistics Extension to 3LPB (SLXKEY = 3) 

Figure 6-27 shows the format of the Statistics Extension to the 
SLPB. 



Hex. 
Byte 



>0C 



>10 
>12 
>14 
>16 * 

Figure 6-27 Statistics Extension to the SLPB 

6.11.5 Interrupt Extension to SLPB (SLXKEY = 4) 

Figure 6-28 shows the format of the Interrupt Extension to the 

SLPB. 



SLDEV3 — 


DEVICE NAME 


SLREAD - 


- TOTAL READ 


OPERATIONS 


SLWRT — 


TOTAL 


WRITE 


OPERATIONS 


SLTOT — 


TOTAL 


OTHER 


OPERATIONS 



Hex. 
Byte 



>0C |SLINT — INTERRUPT LEVEL | SLCHAS ~ CHASSIS OF INT| 
+ + _ + 

>0E |SLPOS — POS. IN CHASSIS | RESERVED 
+ + 

>10 




>14 * 

Figure 6-28 Interrupt Extension to the SLPB 
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6.11.6 Task Extension to SLPB (SLXKEY = 6) 

Figure 6-29 shows the format of the Task Extension to the SLPB. 

Hex. 
Byte 

* + * 

>0C | SLEC — DX10 ERROR CODE | SLIN ID — INSTALLED ID | 
+ + + 

>0E | SLRNID — RUNTIME ID | SLSTID — STATION ID | 
+ + + 

>10 | SLWP6 — WP (WORKSPACE POINTER) | 

+ + 

>12 | SLPC6 — PC (PROGRAM COUNTER) | 

+ + 

>14 | SLST6 ~ ST (STATUS REGISTER) j 

* . * 

>16 * 

Figure 6-29 Task Extension to the SLPB 



6.11.7 Cache Memory Extension to SLPB (SLXKEY = 8) 

Figure 6-30 shows the format of the Cache Memory Extension to the 
SLPB . 



Hex. 
Byte 



>0C 



>0E 



>10 



>12 



SLBANK — CACHE BANK 
(A or B) 



SLPARA — ADDRESS PARITY 
IN BANK A (G or B) 



SLPARB — ADDRESS PARITY 
IN BANK B (G or B) 



SLBAS8 — BASE ADDRESS 
OF CONTROLLER 



SLMEM8 ~ AMOUNT OF 
CONTROLLER MEMORY 



SLEVEN — IS ERROR ON 
EVEN COORDINATE? (Y/ N) 



SLADR8 — TPCS ADDRESS OF CONTROLLER 



>14 * 

Figure 6-30 Cache Memory Extension to the SLPB 
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6.11.8 SLPB Device Extension with PRB (SLXKEY = 9) 

Figure 6-31 shows the format of the SLPB Device Extension with 
PRB. 



Hex. 
Byte 

>0C 

>0E 

>10 

>12 

>14 





| SLEC — DX10 ERROR CODE | SLIN ID — INSTALLED ID 


I SLRNID — RUNTIME ID | SLSTID — STATION ID 


I SLLUNO — LUNO | SLRTRY — RETRIES 


| SLSORF— S=SUCCESS F=FAIL] NOT USED 



SLPRB — PRB THAT CAUSED THE 
DSR TO REPORT THE ERROR 
(12 Bytes) 



>20 



* 



Figure 6-31 SLPB Device Extension with PRB 
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6.12 INTERTASK COMMUNICATIONS (ITC) QUEUE 



A task needing to communicate with other tasks uses the Intertask 
Communications (ITC) queue. This allocated space in the system 
table area holds up to 256 queue IDs, with each ID capable of 
representing more than one message. Duplicate IDs can exist 
since a task calling for a particular ID accesses the first ID of 
the desired number in the queue. When a task accesses a message f 
it removes that message from the queue. Figure 6-32 shows the 
format of the ITC queue. 



Hex. 
Byte 



>00 j ITCLNK ~ ADDRESS OF NEXT ENTRY ON THE QUEUE j 

+ + + 

>02 | ALWAYS ZERO | ITCQID — QUEUE IDENTIFIER] 

>04 | ITCLEN — LENGTH OF MESSAGE 

+ 

>06 




Figure 6-32 Intertask Communication Queue 
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Hex. 

Byte 


Field 
Name" 


>00 


ITCLNK 


>02 




>03 


ITCQID 


>04 


ITCLEN 


>06 


messag: 



Des cription 

This is the address in the system table area 
of the next ITC queue entry. 

Byte 2 is always zero. 

This is the queue ID. Up to 25 6 IDs are 
possible. 

This is the length, in bytes, of the message 
on the queue. 



MESSAGE (S) The message (or messages) begin at byte 6 of 
the ITC queue entry. 



6.13 SYSTEM OVERLAY TABLE (OVT) 

The system overlay table (OVT) is a vector table that contains 
the addresses of many system routine entry points, data 
structures, lists, and queue anchors. It is used by disk 
resident system tasks that are not linked with the DX10 memory 
resident code, but which must refer to and/or use informatigp 
contained therein. The address of the vector table may It, 
obtained via a special SVC, Get System Pointer Table Address. By 
using the table address "as a base register value, a system task 
can refer to any of the addresses within the table by "name. A 
template of the overlay table, showing the labels defined, 
follows. 
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************************* 


* 




OVERLAY 


'table 


************************* 


0000 






DORG 





0000 


0000 


TSKLST 


DATA 





0002 


0000 


UPS 


DATA 





0004 


0000 


PSBLST 


DATA 





0006 


0000 


FIDMAP 


DATA 





0008 


0000 


PF$FCB 


DATA 





000A 


0000 


ETSK 


DATA 





OOOC 


0000 


BPT 


DATA 





OOOE 


0000 


TSKSCH 


DATA 





0010 


0000 


SYSPF 


DATA 





0012 




MM$RLM BSS 


4 


0016 


FFFF 


F$FLG 


DATA 


-1 


0018 


0000 


FUTPDT 


DATA 





00 1A 


0000 


PDTLST 


DATA 





00 1C 


0000 


LDTLST 


DATA 





00 IE 




TM$QRM BSS 


4 


0022 




TMBIDO 


BSS 


4 


0026 




TMTREE 


BSS 


4 


00 2A 


0000 


RSTRID 


DATA 





00 2C 


0000 


RSTRSW 


DATA 





002E 


0000 


SLDATA 


DATA 





0030 




MM$FND 


BSS 


4 


0034 




BM$MPB 


BSS 


4 


0038 


0000 


TSKSTR 


DATA 





003A 


0000 


SYSTAB 


DATA 





00 3C 


0000 


TABSIZ 


DATA 





003E 


0000 


AQPTRS 


DATA 





004 


0000 


TDL 


DATA 





0042 


0000 


KBTAB 


DATA 





0044 




SLPBQC 


BSS 


4 


0048 


0000 


SCIBMX 


DATA 





004A 


0000 


SCIFMX 


DATA 





004C 


0000 


MAPSHD 


DATA 





004E 


0000 


YEAR 


DATA 





00 50 


0000 


UAHEAD 


DATA 





0052 


0000 


SAHEAD 


DATA 





0054 


0000 


KTSKWP 


DATA 





0056 


0000 


KTSKPC 


DATA 





00 58 


0000 


CURMAP 


DATA 





00 5A 


0000 


OADPTR 


DATA 





005C 


0000 


OVLYQ 


DATA 





00 5E 




SO$LTO 


BSS 


4 


0062 




SO$BTO 


BSS 


4 


0066 




SO$RFO BSS 


4 


006A 


0000 


ENDADD 


DATA 





006C 


0000 


ENDLIM 


DATA 





006E 


0000 


MEMS I Z 


DATA 





0070 


0000 


BASADJ 


DATA 





0072 


0000 


TMTOL 


DATA 





0074 


0000 




DATA 





0076 




TM$DOR 


BSS 


4 
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-9701 







************************************** 

(OVT) * 

************************************** 

START OF TSB'S 

ADDR SYSTEM TIME UNITS/SEC 

START OF PSB'S 

ADDR FIXED TASK ID BIT MAP 

ADDR SYSTEM PROGRAM FILE FCB PT 

CURRENT EXECUTING TASK 

BREAKPOINT TABLE 

TASK SEARCH UTILITY 

ADDR OF PATHNAME OF SYSTEM PROG 

TSB CLEAN UP 

FUTIL/UNLOAD LOCKOUT 

FUTIL PDT CURRENTLY IN USE 

START OF PDT'S 

START OF LOT'S 

REM. SPEC. ENT. FROM SPEC. QUEU 

BID TASK ROUTINE 

BUILD TREE LINKAGE 

USER RESTART ID 

CRT 'HELP' KEY DISABLE SWITCH 

SYSTEM LOG DATA 

ALLOCATE USER MEMORY ROUTINE 

MAP BUFFER INTO ADDRESS SPACE 

START OF NON -LINKED TSB'S 

START OF SYSTEM TABLE 

SIZE OF SYSTEM TABLE 

PTR TO ACTIVE QUEUES 

ADDR OF TIME DELAY LIST ANCHOR 

PTR TO 913 STATUS BLOCKS 

SYSTEM LOG QUEUE IN G ROUTINE 

SCI BACKGROUND LIMIT 

SCI FOREGROUND LIMIT 

SCHEDULER MAP FILE POINTER 

BLOCK OF CURRENT DATE AND TIME 

ADDRESS OF MEM MGR HEADER 

ADDRESS OF SYS AREA HEADER 

SUBROUTINE TO KILL I/O - WP 

SUBROUTINE TO KILL I/O - PC 

CURRENT MAP FILE POINTER 

SYSTEM OVERLAY AREA 

LOAD OVERLAY QUEUE 

LINK TO OVERLAY 

BRANCH TO OVERLAY 

RETURN FROM OVERLAY 

LOAD ADR FOR FIRST USER TASK 

LIMIT REG FOR ENDADD 

SIZE OF MEMORY IN BEETS 

ADJUSTMENT VALUE FOR BIAS REG 

START OF TIME ORDER LIST 

SERIAL ACCESS DOOR LOCKING 
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007A 

007E 

0082 

0084 

0088 

008C 

0090 

0094 

0098 

009C 

00A0 

00A4 

00A8 

00AC 

00B0 

00B4 

00B8 

OOBC 

00C0 

00C4 

00C8 

OOCC 

00D0 

00D4 

00D8 

OODC 

OOEO 

00E4 

00E8 

OOEC 

OOFO 

00F2 

00F4 

00F6 

00F8 

OOFC 
0100 
0104 
0108 
010C 
0110 
0114 
0118 

one 

0120 
0124 
0128 
012A 
012C 
012E 
0130 
0132 
0134 



0000 



0000 
0000 
0000 
0000 



0000 
0000 
0000 
0000 
0000 
0000 
0000 



TM$OPN 

BM$FLS 

TM$EXT 

PUS HI 

PUSH 2 

PUSH3 

PUSH4 

PUSH5 

PUSH6 

PUSH7 

PUSH8 

PUSH9 

POPO 

POP1 

POP 2 

POP 3 

POP 4 

POP 5 

POP 6 

POP 7 

POP 8 

POP 9 

MM$RUA 

MM$GSA 

MM$RSA 

MM$GUA 

SCRASH 

TMQUE 

TMDQUE 

TMAQUE 

QHEAD 

STUNIT 

FLG12 

FLGWCS 

RET RID 

* 

FMOPEN 

FMCLOS 

FMWRIT 

WRTSEQ 

CKWRIT 

CKLOCK 

MAPREC 

UPDFDR 

BM$MAP 

BM$RD 

BM$REL 

UAHADD 

ENDDXL 

MEMSW 

DIOPDT 

TLDTSB 

BIDTSB 



4 
4 



BSS 

BSS 

DATA 

BSS 4 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

DATA 

DATA 

DATA 

DATA 

BSS 4 



4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 



BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

BSS 

DATA 

DATA 

DATA 

DATA 

DATA 

DATA 

DATA 



SERIAL ACCESS DOOR UNLOCKING 

BUFFER MGMT FLUSH ROUTINE 

INFINITE EXTEND TIME SLICE 

SAVE REG Rl 

SAVE REGISTERS R1-R2 

SAVE REGISTERS R1-R3 

SAVE REGISTERS R1-R4 

SAVE REGISTERS R1-R5 

SAVE REGISTERS R1-R6 

SAVE REGISTERS R1-R7 

SAVE REGISTERS R1-R8 

SAVE REGISTERS R1-R9 

EXIT ROUTINE 

RESTORE Rl 

RESTORE REGISTERS R1-R2 

RESTORE REGISTERS R1-R3 

RESTORE REGISTERS R1-R4 

RESTORE REGISTERS R1-R5 

RESTORE REGISTERS R1-R6 

RESTORE REGISTERS R1-R7 

RESTORE REGISTERS R1-R8 

RESTORE REGISTERS R1-R9 

RETURN USER AREA MEMORY 

GET SYSTEM AREA 

RETURN SYSTEM AREA 

GET USER AREA 

SYSTEM CRASH ROUTINE 

GENERAL QUEUEING ROUTINE 

GENERAL DEQUEUE IN G ROUTINE 

QUEUE ON ACTIVE QUEUE 

ADDR OF SVC QUEUES 

CLOCK TICKS / SYSTEM TIME UNIT 

MACHINE FLAG 0=/10,-l=/12 (VAL) 

WCS FLAG 0=NO; 1=YES - (VALUE) 

RETURN RUN TIME ID 

FMT FILE OPEN PROCESSOR 

FMT FILE CLOSE PROCESSOR 

FMT FILE WRITE PROCESSOR 

SEQUENTIAL FILE WRITE 

CHECK WRITE ACCESS 

CHECK IF RECORD LOCKED 

TRANSLATE BLOCK # TO ADU # 

UPDATE FILE DESCRIPTOR RECORD 

MAP IN TASK BUFFER 

RETRIVE FILE BLOCK 

RELEASE FILE BLOCK 

BEET ADDRESS OF UAHEAD 

LIMIT REG VALUE FOR DX-10 

USER MEMORY SIZE SWITCH 

ADDRESS OF DISC PDT 

TSB FOR TASK LOADER 

* * * RESERVED * * * 

TSB FOR BID TASK 
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U36 


0000 


TQLBET 


DATA 





0138 


0000 


OF$FCB 


DATA 





013A 


0000 


RF$FCB 


DATA 





013C 


0000 


OF$LDT 


DATA 





013E 


0000 


PF1LDT 


DATA 





014 


0000 


PF2LDT 


DATA 





014 2 


0000 


PF3LDT 


DATA 





0144 


0000 


RF$LDT 


DATA 





0145 


0000 


SCR$KD 


DATA 





0148 


0000 


SCR$TK 


DATA 





014 A 


0000 


SCR$SC 


DATA 





014C 


0000 


SCR$DA 


DATA 





014E 


0000 


TOLLNK 


DATA 





0150 


0000 


RIDMAP 


DATA 





0152 


0000 


CMEMSZ 


DATA 





0154 


0000 


SCNPDT 


DATA 





0156 


0000 


SYSPFN 


DATA 





0158 


0000 


SCR$SL 


DATA 





015A 


0000 


XY 


DATA 





015C 


0000 


UNLPDT 


DATA 





015E 


0000 


SCHDWS 


DATA 





0160 


0000 


SLCSUS 


DATA 





0162 


0000 


BM$SIZ 


DATA 





0164 


0000 


MMUMAX 


DATA 





0166 




FM$RDM 


BSS 


4 


016A 




BM$MP2 


BSS 


4 


J16E 




TM$INC 


BSS 


4 


0172 




TM$DEC 


BSS 


4 


0176 




TM$CLR 


BSS 


4 


017A 


0000 


S$$PAT 


DATA 





017C 


0000 


CTRYCD 


DATA 





017E 


0000 


TM$T0 


DATA 





0180 


0000 


MM$PAK 


DATA 







0182 


OVTSIZ 


EQU 


$ 


0000 






RORG 





FIRST BEET TIME ORDERED 

FCB ADDRESS OF OVERLAY 

ROLL FILE FCB 

OVERLAY FILE LDT 

LDT FOR LUNO D 

LDT FOR LUNO B 

LDT FOR LUNO F 

ROLL FILE LDT 

HEAD ADR CRASH FILE 

CYLINDER ADR CRASH 

SECTOR ADR CRASH FILE 

TILINE ADR CRASH FILE 

TOL LINKAGE ROUTINE 

ADR RUN TIME ID BIT MAP 

MEMORY TO BE CRASH DUMPED 

DSR POWER UP ROUTINES 

NAME OF SYSTEM PROGRAM FILE 

CRASH FILE UNIT SELECT 

TRAP INITIALIZATION TABLE 

UNLOAD PDT CURRENTLY IN USE 

SCHEDULER WORKSPACE 

SCHEDULER ENTRY POINT 

LENGTH OF MEM RESIDENT BUFFER 

MAXIMUM SIZE FREE USER AREA 

READ MULTIPLE 

CHECK MEMORY PROTECTION 

INCREMENT TM$EXT BLWP VECTOR 

DECREMENT TM$EXT BLWP VECTOR 

CLEAR TM$EXT BLWP VECTOR 

BEGINNING OF PATCH AREA 

COUNTRY CODE 

POINTER TO TM$T0 

MEMORY PACK REQUEST FLAG (NOT A POIN 
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6.14 MEMORY MANAGEMENT LISTS 

In addition to the time ordered list (TOL), which is a list of 
all allocated blocks of user memory (as opposed to system table 
area), two free memory lists are maintained by memory management. 

One is a list of free blocks of system table area and is headed 
by the SAHEAD anchor in the D$DATA module. The list is singly 
linked and ordered by increasing address of the free block. Each 
free block contains the following overhead in the first four 
bytes: 

Descripti on 

Size of block in bytes 
Link to the next block 

When a block of system table area is allocated, the size of the 
block is stored in the word immediately preceding the first word 
of the allocated block (that is, negative offset). 

The other list contains free user memory blocks, and is headed by 
the UAHEAD anchor in the D$DATA module. The list is also singly 
linked and ordered by increasing address. Each block contains art 
overhead beet as described in paragraph 6.8 on the Time Ordered 
List (TOL) . 



6.15 SEQUENTIAL FILE BACKUP STRUCTURE 

By using the Backup Directory command, a directory can be backed 
up to a sequential file. The following are two examples of the 
structures of the sequential files created by backing up the 
directory of Figure 6-33 while using the control file of Fiqure 
6-34. 

Figure 6-35 shows the expanded structure of the backup of a 
program file. In Release 3.3, the block option was introduced. 
The block option causes information to be blocked in physical 
records of 9600 bytes (this may be altered in the Backup 
Directory PROC) . The records are packed by preceding each 
logical record by a character count. An EOF (end of file) is 
represented by a zero count. The first record (the label) is not 
packed. The backup directory is still terminated by two physical 
EOFs when blocking is selected. Also, the tape label is extended 
from 7 words to 15 words. 
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SRC 



VCATALOG 



UT 



GLEN 



ANNA 



OBJ 



©0©0 



LST 



SRC 



ALIASES 

CI FOR C 
B1 FOR B 
A1 FOR B 
A2 FOR A 



OBJ 



LST 



®©0®© ©0©©0©©©© 



OBJ 2 



(new) (° LD j 



2278137 



Figure 6-33 Directory To Be Backed Up 
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MOVE 

EXCLUDE 

MOVE 

EXCLUDE 

MOVE 

EXCLUDE 

MOVE 

END 



. UT . GLEN . SRC , . SEQF I LE 

B 

•UT. GLEN. OBJ 

B 

.UT.OLEN.LST 

B 

-UT.ANNA 



Figure 6-34 Control File 



/ 



FOR S$FROGA 



DATA S$PROGA 



/ 



/ 



N 



* 


INSTALL SVC FOR A 




MODULE A 




INSTALL SVC FOR B 




MODULE B 




• 




• 




• 







2278138 



Figure 6-35 Expanded Structure for a Program File 
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6.15.1 Backup Directory with NOMULTI Option Selected 

Figure 6-36 represents the format of a tape created by the Backup 
Directory utility with the NOMULTI option specified. The 
MULT I /NOMULTI option was available on Release 3.2 and earlier. 
Later releases use the MULT I format exclusively. The only 
difference between the two formats is a header used by the MULTI 
format that begins every volume. 

The first record written is the directory overhead record (DOR) 
of the first directory. Following the DOR are the FDRs and data 
records of the files under the directory. The end of the 
directory is noted by an EOD marker. The EOD marker is a recocd 
consisting of the following four bytes: EODb where b equals a 
blank space. 
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2278139 (1/5) 



WWWW eqfWWW^ 



DOR OF .UT. GLEN. SRC 



FDR OF A 



DATA OF A 



^ 



FDR OF C 



DATA OF C 



v\\\\\\\eof\\\\\\\\ 



\ 



EOD MARKER 



DOR OF .UT. GLEN. OBJ 



FDR OF A 



\\\\\\\\ EOF WWV^ 



DATA OF A 



FDR OF 0BJ2 



FDR OF NEW 



DATA OF NEW 



Figure 6-36 Structure of .SEQFILE (Sheet 1 of 5) 
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\\\\\\\\\pr\\\\W 



FDR OF OLD 



DATA OF OLD 



N 



EOD MARKER 



FDR OF C 



DATA OF C 

K\\\\\\\W\\\\\\^J 



EOD MARKER 



DOR OF .UT.GLEN.LST 



FDR OF A 



DATA OF A 



\\\\\\\\\E°F\\\\\\^\ 



ADR OF Al 



2278139 (2/5) 



ADR OF A2 



Figure 6-36 Structure of .SEQFILE (Sheet 2 of 5) 
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2278139 (3/5) 



\\\\\\\\\^\\\\\\^ 



FDR OF C 



DATA OF C 



ADR OF CI 



EOD MARKER 



DOR OF. UT. ANNA 



FDR OF SRC 



FDR OF X 



DATA OF X 



WVWWWWW^W 



FDR OF Y 



DATA OF Y 



\\\\\\\\ E°F \\\\\\W 



FDR OF Z 



Figure 6-36 Structure of .SEQFILE (Sheet 3 of 5) 
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DATA OF Z 
k\\\\\\\\E0F\\\\\^ 



EOD MARKER 



FDR OF OBJ 



DFR OF X 



DATA OF X 



\\\\\\\\\ eof S555S 



FDR OF Y 



DATA OF Y 



vWWWWor \\W\^ 



DFR OF Z 



DATA OF Z 

K\\\\\\\ e°f \\\\\\^l 



EOD MARKER 



FDR OF LST 



Figure 6-36 Structure of .SEQFILE (Sheet 4 of 5) 
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3278139 (5/5) 



FDR OF X 



DATA OF X 



\\\\\\\\ eofWWX^ 



FDR OF Y 



DATA OF Y 



WWWW E °f WYA^ 



FDR OF Z 



DATA OF Z 



\\\\\\\\ EOF \\\WW 



EOD MARKER 



EOD MARKER 



te:r^ 



Figure 6-36 Structure of .SEQFILE (Sheet 5 of 5) 
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NOTE 

An EOD marker is a record with EODb in the 
first four bytes, where b equals a blank 
space. 



6.15.2 Backup Directory with MULTI Option Specified 

The MULTI option is specified when a directory is being backed up 
to magnetic tape and the directory spans more than one tape 
volume . 

If the MULTI option is specified, the first record written to the 
sequential file is a header record (see tape 1, Figure 6-37) . 
The header record consists of the following words: 



Word 



Contents 



1-3 The ASCII characters **HDR* 

4-7 Date and time as returned from SVC call 

8 Tape volume number 

9 Blocking factor 
10-15 Reserved 

After the header record, the file has the same structures as the 
NOMULTI file. 

When the end of tape is encountered by Backup Directory, the 
record being written to tape is saved to be written to the next 
tape. After the tape has been changed, a header record is 
written to the new tape (see Tape 2, Figure 6-37). The header 
record has the same format as the header record of the first 
tape, except that the volume has been incremented by 1. The date 
and time written will be the same as that of the first tape. The 
record being written when the end of tape was encountered is then 
written and the backup continues. 
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TAPE 1 



MULT1 VOLUME HEADER 

**HDR* 

DATE 

VOL 1 



DOR OF .UT. GLEN. SRC 



FDR OF A 






DOR OF .UT.ANNA 



FDR OF SRC 



FDR OF X 



DATA OF X 



END OF TAPE 



2278140 



TAPE 2 



wwww e \\\\\v^ 



MULTI VOLUME HEADER 
**HDR* .DATA, VOL 2 



CONTINUATION OF 
DATA OF X 



FDR OF Y 



DATA OF Z 



WWW\W°WW\WW 



EOD MARKER 



EOD MARKER 



,\\\ww e . \\\\\s. 

\\\\\\\\ E ° F wwww 



END OF DIRECTORY 



Figure 6-37 Back-up Directory Tape Format 
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6.16 PHYSICAL RECORD BLOCK (PRB) 



A Physical Record Block (PRB) resembles an I/O SVC call block. 
The difference between the two is that the PRB does not include 
the first 2 bytes of the SVC call block (the 00 SVC code and the 
SVC error code) . Figure 6-38 shows the format of the PRB. 



Hex. 



Byte 

* + * 

>00 | PRBBOC — SUB-OPCODE j PRBLUN — LUNO | 

+ . + + 

>02 |PRBSFL — SYSTEM FLAGS | PRBUFL — USER FLAGS | 
+ + + 

>04 j PRBDBA — DATA BUFFER ADDRESS | 

+ , + 

>06 | PRBLRN — LOGICAL RECORD LENGTH | 

+ + 

>08 | PRBCHT — CHARACTER COUNT | 

+ + 

>0A | PRBRPA ~ REPLY BLOCK ADDRESS 1 

+ + 

Figure 6-38 Physical Record Block 
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Hex . 
Byte' 

>00 

>01 

>02 

>03 

>04 
>06 

>08 

>0A 



Field 
Name 

PRBBOC 

PRBLUN 

PRBSFL 

PRBUFL 



PRBDBA 



PRBLRN 



PRBCHT 



PRBRPA 



Description 

This is the subopcode of the I/O SVC code >00. 

This is the logical unit number (LUNO) 
assigned for the operation. 

The system flags, set and reset by DX10 , are 
the diagnostic extension to the PRB. 

The user flags can indicate many things. A 
few examples are reply requested, variable 
sector length, logical track addressing, and 
I/O by ADD number. 

This is the data buffer address. (it must be 
even . ) 

This is the logical record length, which 
specifies the number of characters that can be 
stored in an input buffer. 

The character count specifies the number of 
characters to be output. 

The reply block address is used for output 
operations if the call block specifies a 
reply. 
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Section 7 
DX10 Data Base Modules 



7 . 1 GENERAL 

Part of the memory resident DX10 kernel consists of the two DX10 
data base modules, D$DATA and DXDAT2. The data base is split 
into two modules in order to separate sysgen dependent data from 
static data. Constant data is contained in DXDAT2. The D$DATA 
module is built by GEN990, and contains all of the system 
generation dependent data. The following paragraphs describe the 
contents of the two data modules. 



7.2 D$DATA 

The D$DATA template is in file .DXMISC. SOURCE. D$DATA on the 
source disk. The first section of this module contains system 
constants, list headers, list pointers, and a table of user 
defined SVCs. Examples of system constants include the time 
slice value and the size of the system table area. One example 
of a list pointer is ETSK, a pointer to the task status block 
(TSB) of the currently executing task. 

The next section of D$DATA contains TSBs for a file management 
task (FM$TSK) for each disk drive and the task bidder (TMSBID) . 

A keyboard status block (KSB) table follows the TSBs. Each entry 
in the table points to the KSB for the station whose ID 
corresponds to the table index. The first table entry points to 
the KSB for ST01, the second to the KSB for ST02, and so on. 

The next section of the D$DATA module contains the physical 
device table (PDT) for every device defined in the system, 
including the KSBs for all terminals. 

Following the PDTs are the global logical device tables (LDTs) . 
There is a global LUNO (represented by an LDT) assigned to every 
disk drive, and one assigned to ST01. 

The remainder of the D$DATA module contains system log data, the 
system table area, the breakpoint table, the system overlay 
areas, the interrupt and XOP trap initialization table (written 
to locations >00->7F by the DX10 image loader) , and the interrupt 
decoding module. 
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7.3 DXDAT2 

The DXDAT2 source module is on the file named 
.DXMISC. SOURCE. DXDAT2 on the source disk. The constant data base 
module contains system SVC information, queue anchors for most 
system queues, and TSBs for some link-in system tasks. 

The first section of this module is a table of constants which 
are often used by DX10 routines. The next section is a vector 
table of SVC processor addresses, and is used by the SVC 
interpreting code. Following the vector table is a table of the 
lengths of all supervisor call blocks. This table is used by the 
SVC interpreter, to find out how much call block needs to be 
buffered before passing control to the SVC processor. 

The next section contains the anchors for most of the DX10 
queues. Each anchor is of the form described in the data 
structures section. 

Following the queue anchors is the list of SVC definition blocks 
which are used by the SVC unbuffering task, SVCCLN, to decide 
what information needs to be returned (unbuffered) to a task 
which has issued an SVC processed by a queue server. The list is 
terminated by a zero word. 

The next section of DXDAT2 is a list of return field definitionsj 
which is used by SVCCLN to determine which fields within I 
buffered supervisor call block need to be unbuffered into the 
calling task. This list is also ended by a zero word. 

The next section contains task status blocks for the followinq 
lmked-in system tasks: 

* Task loader (TM$LDR) 

* Overlay loader (TM$OVY) 

* Disk manager (DM$TSK) 

* SVC clean up task (SVCCLN) 

* System overlay loader (SOVLDR) . 

The remainder of the DXDAT2 module contains the workspace used bv 
the scheduler to update the time and date. 
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Section 8 
Common System Routines 



8.1 STACKING ROUTINES 

Routines in DX10 use runtime stacks for passing parameters, 
storing registers and return information, and loading registers. 
In order to allow several routines that share a common workspace 
to use the same stack, RIO is reserved in DX10 routines as a 
pointer to the top of the stack (next available entry) . Several 
stack handling routines, PUSHn and POPn, are used to store data 
on, and retrieve data from a stack. 

PUSHn is used to store registers Rl-Rn on the stack, (where n is 
less than or equal to 9) . PUSH automatically increments the 
stack pointer, RIO, to point to the top of the stack. To call 
PUSH, execute a BL to @PUSHn. For example: 



BL @PUSH3 STORE R3 , R2 , Rl 

or 
BL @PUSH9 STORE REGISTERS 9-1 



PUSH stores the registers starting with the highest numbered 
register (that is, a call to PUSH3 will store R3 first, then R2, 
and finally Rl) , and always clear RO. 

Before calling PUSH, a routine must store its return address 
(usually the value of Rll , if the routine was called via a BL 
instruction) on the stack. The example at the end of this 
description shows the general DX10 convention for using PUSH. 

POPn is used to load registers Rl-Rn from the top n words of the 
stack, and to return from a subroutine. Again, n is less than or 
equal to 9. POPn automatically decrements the stack pointer, 
RIO, to point to the new top of the stack. Registers are loaded 
starting with Rl. POP is entered by executing a B instruction to 
POPn. 
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POPO is a special entry point into POP, and is always executed at* 
the end of any call to POP. POPO loads Rll with the top word of 
the stack. This should contain the address of the word following 
the instruction which branched to the routine now using POP. If 
RO is zero {that is, the routine is not returning any errors), 
control returns to the word following the address in Rll. If RO 
is non-zero (error condition) but the value of the word addressed 
in Rll is zero (no error return address) , control also returns to 
the word following the address in Rll. If RO and the word 
addressed by Rll are both non-zero, control returns to the 
address contained in the word pointed to by Rll. 

A conventional call to a subroutine which uses PUSH and POP is: 



BL @SUBR Call to subroutine 
DATA ERROR Error return address 
NORML EQU $ Normal return point 

The following example shows such a subroutine call: 
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REF PUSH5,POP5 
COPY .SYSTEM. TABLES. 



ORS 



* OFFSETS FOR REGISTER STACK 
* 



OR1 


EQU 


-2 


OR2 


EQU 


-4 


OR3 


EQU 


-6 


OR4 


EQU 


-8 


OR5 


EQU 


-10 


OR6 


EQU 


-12 


OR7 


EQU 


-14 


OR8 


EQU 


-16 


OR9 


EQU 


-18 


STACK 

* 


BSS 


30*2 


WS 

it 


• 

BSS 


16*2 


♦THIS 


• 

IS THE 


MAIN PROGRAM 


MAIN 
* 

* 


LI 


RIO, STACK 


* 


BL 


@SUBR 




DATA 


ERROR 


NORML 
* 

* 


EQU 

• 


$ 


* 


• 
• 

RT 




ERROR 
* 


EQU 

* 


$ 


* 
*THIS 


• 
• 

IS THE 


SUBROUTINE 


SUBR 


MOV 


R11,*R10+ 


* 


BL 

• 


@PUSH5 


* 

EXAMPL 


EQU 


$ 




MOV 


@RVAL,@OR2(R10) 


* 


B 


@POP5 


SUBERR 


EQU 


$ 




LI 


R0,ERRCOD 




B 


@POP5 




END 





CREATE A 30 -WORD STACK 
CREATE A WORKSPACE 

INITIALIZE STACK POINTER, RIO 



CALL SUBROUTINE 

THIS IS THE ERROR RETURN ADDRESS 

THIS IS THE NORMAL RETURN 



RETURN TO THE CALLING PROGRAM 



STORE RETURN ADDRESS ON STACK 
STORE R1-R5, CLEAR R0 



NORMAL EXIT 

STORE RETURN VALUE IN STACKED R2 
RESTORE R1-R5, RETURN TO MAIN 

ERROR EXIT 

PUT ERROR CODE IN R0 

RESTORE R1-R5, TAKE ERROR RET IN MAIN 
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Elements of a stack may be accessed without using PUSH and POIf 
by using offsets into the stack indexed by the stack pointer,' 
RIO, (as in EXAMPL above). The top word on the stack is at 
address @-2(RlO), the next word is at @-4(RlO), and so on down 
into the stack. Offsets for registers pushed onto a stack are 
given in .SYSTEM. TABLES. ORS. 



8.2 QUEUEING ROUTINES 

There are six routines used within DX10 to add or delete entries 
from the various data queues. The routines are memory resident, 
and are located in the module TM$QUE. The routines are: TMAQUE, 
TMAQO, TMQUE, TMDQUE, TMTSBQ, and TM$QRM. These routines may be 
entered by memory resident system tasks by executing a BL to the 
name of the routine. Input register and stack requirements are 
given for each routine in the following paragraphs. Disk 
resident system tasks may access all of the routines except TMAQO 
via the system overlay table. 



or 

( 



8.2.1 TMQUE 

This is the general queueing routine. It places the specified 
data structure (any type) on the specified queue. The address of 
the structure to be queued is expected to be in R2. The addre 
of the queue anchor should be in Rl. TMQUE requires from 6 to 
words of stack, according to the following conditions: 

1. The queue has no dedicated server task — 6 words. 

2. The queue has a dedicated, memory resident server 
task — 12 words. 

3. The queue has a dedicated, disk resident server 
task — 24 words. 



When the data structure is placed on the queue, TMQUE checks two 
conditions. If the queue has a dedicated server task, and the 
task is terminated, TMQUE bids the task (calls TMBIDO) . If the 
queue server is in memory in state >24, it is activated directly. 
If the queue is a TSB queue (entries are TSBs) , then the TSB that 
has just been queued is given the task state contained in the 
queue anchor (see paragraph 6.2 on queues). 



8-4 



939153-9701 



System Design Document Commom System Routines 



8.2.2 TMAQUE 

This routine puts the specified TSB on the active queue for that 
task's priority. TMAQUE uses six words of a stack. The routine 
expects Rl to contain the address of the TSB to be queued. The 
TSB flags are checked to see if the task. has been allocated 
memory. If it does not have memory, TMAQUE calls TMAQU to put 
the task on the waiting on memory queue, TMWOM. If the task 
already has memory, TMAQUE checks the TSB priority, and calls 
TMQUE to put the task on the active queue for that priority. 

8.2.3 TMAQO 

This routine puts the specified TSB on the active queue at 
position one for priority one tasks. The task loader and the 
system overlay loader use TMAQO so that tasks which have just 
been loaded will get a good chance of executing at least once 
before being rolled. 

TMAQO uses six words of stack. The routine expects Rl to contain 
the TSB address of the task to be queued. 

8.2.4 TMTSBQ 

This routine queues the specified TSB on the specified queue. 
TMTSBQ is actually a second entry point to TMQUE, and is 
therefore the same routine. 



8.2.5 TMDQUE 

This is the general dequeueing routine. It is used to remove an 
entry from the head of the specified queue. The routine uses one 
word of a stack. The address of the dequeued anchor should be in 
Rl. TMDQUE will return the address of the dequeued data 
structure in R12, or an error message in RO. The only error code 
is 1, which means the queue is empty. 

8.2.6 TM$QRM 

This routine is used to remove any specified entry from the 
specified queue. It requires one word of stack. The address of 
the queue anchor should be in Rl, and the address of the 
structure to be removed from the queue should be in R2. TM$QRM 
searches through the queue for an entry with the address 
specified in R2. If no such entry is in the queue, an error code 
of 1 is returned in RO. Otherwise, the structure is removed from 
the queue. 
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Section 9 
Description of DX10 Routines 



9 . 1 GENERAL 

This section breaks the major DX10 routines into functional 
categories (such as task management, file management, and so on,) 
and describes each routine briefly. Several tables in the 
section show how you can find the routine source on a DX10 source 
disk. 



9.2 SVC PROCESSING 

SVC processing includes individual SVC processing routines and 
several overhead routines that are involved in decoding SVCs and 
buffering and unbuffering supervisor call blocks. Tables 9-1 and 
9-2 show the routines that process SVCs. 
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Table 9-1 SVC Overhead Routines 



Routine Source Module Pathname 
SVC INT .DXMISC. SOURCE. SVC INT 



Descripti on 

Interprets XOP 15 by 

accessing the user's call 
block and SVC code. Looks up 
the SVC processor address in 
SCTAB (DXDAT3 module), and 
SVC map file offset in SVCFLG 
(DXDAT4 module) , then 

transfers control to that 
address. 



SVCBUF 



. DXMISC . SOURCE . SVCBUF 



SVCFND 



•DXMISC . SOURCE . SVCBUF 



Buffers user call blocks for 
SVCs processed by queue 
serving tasks into the system 
table area. Calls TMQUE to 
queue the buffered call 
block, bids the queue server, 
and calls SVCFND. 

Looks up the SVC definition 
block in the DXDAT4 table, 
SVCDEF. 



SVUBUF 



. DXMISC . SOURCE . SVCBUF 



SVCCLN 



. DXMISC . SOURCE . SVCCLN 



Buffers the user's call block" 
and any expansion blocks (as 
defined in the definition 
block retrieved by SVCFND) 
into system table area. 

Unbuffers the buffered call 
block after a queue serving 
SVC processor terminates. 
SVCCLN may have to cause the 
task to be rolled in. The 
task is reactivated after the 
unbuffering, and the buffer 
is released to the system 
table area. 



MAPSWT 



, DXMISC . SOURCE . MAPSWT 



When the SVC does not reside 
in the same map file as the 
scheduler map file, this 
module is called from SVCINT. 
This routine loads the 

appropriate map file for the 
given SVC. 
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Table 9-2 SVC Processors — Part 1 of 2 



SVC 
Code 



SVC 
Title 



XOP(X) 
Queue (Q) Processor 



Server 



Name 



Source 

Module 

Pathname 



00 I/O 

01 Wait for I/O 

02 Time Delay 

03 Date and Time 

04 End of Task 

05 Bid Task 

06 Unconditional Wait 

07 Activate Suspended 
Task 

09 Do Not Suspend 

0A Convert Binary to 

Decimal 
0B Convert Decimal to 

Binary 
0C Convert Binary to 

Hexadecimal 
0D Convert Hexadecimal 

to Binary 
0E Activate Time Delay 

task 
OF Abort I/O (LUNO) 

10 Get Common Data 
Address 

11 Change Priority 

12 Get Memory 

13 Release Memory 

14 Load Overlay 

15 Disk File Utility 

16 End of Program 

17 Get Parameters 

IB Return Common Data 

1C Put Data 

ID Get Data 

IF Scheduled Bid Task 

20 Install Disk Volume 

21 System Log SVC 

22 Disk Manager 

24 Suspend Awaiting 
Queue Input 

25 Install Task 

26 Install Procedure 

27 Install Overlay 

28 Delete Task 

29 Delete Procedure 
2A Delete Overlay 
2B Execute Task 

2C Read/Write TSB 



X 


DXIOS 


X 


WAITIO 


X 


TDLY 


X 


DTTIM 


Q 


ENDTSK 


Q 


TM$SBD 


X 


UNCDWT 


X 


ACTTSK 


X 


HOTSK 


X 


CBDA 



CDAB 



X 


CBHA 


X 


CHAB 


X 


ATDLYT 


X 


ABTIOX 


X 


GETCOM 


X 


CHGPRI 


Q 


MM$GTM 


X 


MM$RTM 


Q 


TM$OVY 


Q 


FUTIL 


Q 


ENDPGM 


X 


GETPRM 


X 


RETCOM 


X 


PUTDAT 


X 


GETDAT 


Q 


TM$SBD 


Q 


INSTAL 


Q 


SLSVC 


Q 


DM$TSK 


X 


SUSPQI 


Q 


PF$LIN 


Q 


PF$LIN 


Q 


PF$LIN 


Q 


PF$LDE 


Q 


PF$LDE 


Q 


PF$LDE 


Q 


EXCTSK 


X 


TSBRWT 



.DXIO . SOURCE . DXIOS 
.DXIO. SOURCE. WAITIO 
.TSKMGR . SOURCE . TM$FUN 
.TSKMGR. SOURCE. TM$FUN 
.TSKMGR . SOURCE . TM$FUN 
.SYSTSK. SOURCE. TM$SBD 
.TSKMGR. SOURCE. TM$FUN 
.TSKMGR. SOURCE. TM$FUN 

. TSKMGR . SOURCE . TM$FUN 
. DXMISC . SOURCE .CNVRSN 

. DXMISC . SOURCE .CNVRSN 

•DXMISC . SOURCE .CNVRSN 

. DXMISC . SOURCE .CNVRSN 

.TSKMGR. SOURCE. TM$FUN 

.DXIO . SOURCE . ABTIOX 
. TSKMGR . SOURCE . TM$CMN 

. TSKMGR . SOURCE . TM$FUN 
.MEMMGR. SOURCE .MM$SVC 
•MEMMGR . SOURCE . MM$SVC 
.TSKMGR . SOURCE . TM$OVY 
.FUTIL. SOU RCE.FU$ 
. TSKMGR . SOURCE . TM$FUN 
. TSKMGR . SOURCE . TM$FUN 

. TSKMGR . SOURCE . TM$CMN 
. TSKMGR . SOURCE . TM$ IQ 
. TSKMGR . SOURCE . TM$ IQ 
•SYSTSK. SOURCE. TM$SBD 
. SYSTSK . SOURCE . INSTAL 
. SYSTSK . SOURCE . SYSLGY 
.DSCMGR. SOURCE. DM$TSK 
. TSKMGR. SOURCE .TM$ROT 

(SYSTEM TASK) 



(SYSTEM TASK) 



.TSKMGR. SOURCE. TM$FUN 
. TSKMGR. SOURCE .TSBRWT 
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Table 9-2 SVC Processors — Part 2 of 2 



svc svc 

Code Title 

2D Read/Write Task 



XOP(X) 

Queue (Q) 

Server 



2E Self Identification X 

2F End Action Status X 

30 Get Event Character X 

31 Map Program Name Q 
to ID 

32 Get Overlay Table X 
Address 

33 Kill Task Q 

34 Unload Disk Volume Q 

35 Poll Status of Task X 
in Terminal Task Set 

36 Wait on Multiple X 
Initiate I/Os 

37 Assign Space on Q 
Program File 

38 Initialize Disk Q 
Volume 

39 Get Event Character X 
3B Initialize Date X 

and Time 

3E Reset End Action x 

3F Retrieve System Data X 



Processor 
Name 

TM$BID 



TM$SID 
TM$EAS 
GTEVNT 
PF$LMN 

GTOVYT 

SVCKIL 
INSTAL 
TM$ST 

WAN Y 10 

PF$LAS 

IN VOL 

GTEVTL 
SDTIM 

RSTEAC 



Source 

Module " 
Pathname 

.TSKMGR. SOURCE. TM$BI 
.TSKMGR. SOURCE. TM$RW 
. TSKMGR . SOURCE . TM$RW 
•TSKMGR. SOURCE. TM$FU 
. TSKMGR . SOURCE . TM$EA 
. DXIO . SOURCE . GETEVT 
(SYSTEM TASK) 



.TSKMGR. SOURCE. TM$FU N 

.SYSTSK. SOURCE. SVCK I L 
.SYSTSK. SOURCE. INSTA L 
.TSKMGR. SOURCE. TM$FU N 

.DXMISC. SOURCE. WAITI 

(SYSTEM TASK) 

. SYSTSK . SOURCE . INVOL 

. DIO . SOURCE .GETEVT 
.TSKMGR. SOURCE. TM$DT M 

•TSKMGR. SOURCE. TM$FU N 
.TSKMGR. SOURCE :TM$FU N 



9.3 BID TASK SUPERVISOR CALL — CODE >0 5 

The Bid Task supervisor call is included in DXIO 3.4 and later 
releases for compatibility with DXIO 2.X releases. Because this 
SVC may be deleted in later releases, you should avoid using the 
Bid Task SVC. The System Design Document discusses it for 
informative purposes only. 

Use the Bid Task SVC only for tasks that have been installed on 
the single system program file and that were designated as non- 
replicatable. The operating system task TMSBD transmits the call 
to an Execute Task (>2B) SVC. The task is bid with no associated 
station, and the calling task is not suspended. 

The call block for the Bid Task supervisor call is eight bytes in 
length and must be aligned on a word boundary. The contents of 
each byte in the supervisor call block are as follows: 
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3 Y te ° Contains the code for the Bid Task supervisor call 

and must be >0 5. 
Byte 1 Used by the system to return an error code, if 

necessary. 
Byte 2 Contains the installed ID of the task to be executed 

on the system program file. 
Byte 3 Reserved. 
Bytes 4-7 Used to pass user-specified parameters to the called 

task. The called task must issue a Get Parameters 

supervisor call to obtain the parameters. 

The following example of a Bid Task supervisor call specifies 
that task >5E be loaded from the system program file. The ASCII 
representation of the characters HELP are passed to the called 
task. 

EVEN FORCE ALIGNMENT ON A WORD BOUNDARY 

BIDT BYTE >05 CODE FOR BID TASK 

ERRC BYTE >00 SET BYTE ONE TO ZERO 

ID BYTE >5E INSTALLED ID OF TASK TO BE EXECUTED 

BYTE >00 RESERVED (SET TO ZERO) 

PARMS TEXT 'HELP' FOUR BYTES PASSED TO CALLED TASK 

Within the procedure portion of the calling task, this statement 
initiates the Bid Task supervisor call: 

XOP BIDT, 15 

Error codes returned in byte 1 of the supervisor call block are 
as follows: 

Error Code Meaning 

>04 Signifies successful completion. This code 

is for compatablity with previous releases." 

>FF The specified task is not on the system 

program file, or the specified task is on 
the system program file, but is 

replicatable, or an error occurred when the 
translated Execute Task SVC was performed. 

Other A task state is returned. This is the 

state of the called task if it is already 
in execution. Or, if a currently running 
task allocated the run ID corresponding to 
the called task's installed ID, that task's 
state is returned as an error code. 
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9.4 TASK MANAGER 

The main routines involved in task management are the scheduler, 
task loader, overlay loader, system overlay loader, and the task 
managing SVCs. The task loader also works closely with memory 
management routines, which the next paragraph discusses. 

Table 9-3 shows the major task management routines. 

Table 9-3 Task Management Routines — Part 1 of 5 

Routine Source Module Pathname Description 



TM$SHD 



TM$LDR 



TM$OVY 



.TSKMGR . SOURCE . TM$SHD 



. TSKMGR . SOURCE . TM$LDR 



•TSKMGR . SOURCE . TM$OVY 



SOVLDR 



.DXMISC . SOURCE . SOVLDR 



SO$LTO 



.DXMISC . SOURCE . SO$CPR 



Task scheduler. Updates 
time, date, and delayed 
tasks, bids SCI, and selects 
the next task to execute. 

Task loader. Loads tasks and 
procedures, rolls out quieted 
tasks and tasks that issue 
Get Memory SVCs. 

Overlay loader. Loada 
overlays requested by tasks. 
Requests are .queued for the 
overlay loader, which loads 
the overlay and calls TMAQUE 
to put the task on an active 
queue. TM$OVY calls file 
management routines to read 
the overlay from disk. 

System overlay loader. 
Serves the queue SOVYQ. TSBs 
of tasks that have called 
system overlays are queued on 
SOVYQ. SOVLDR loads the 
correct overlay and 
reactivates the task, calling 
TMAQO. 

Link to system overlay. A 
task or an overlay calls this 
routine to link to a system 
overlay. If the desired 
overlay is in memory, the TSB 
is altered to link in the 
overlay; otherwise, the TSB 
is queued for SOVLDR and th, 
task is suspended. 
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Table 9-3 Task Management Routines — Part 2 of 5 
Routine Source Module Pathname Description 



SO$BTO 



.DXMISC . SOURCE . SO$CPR 



SO$RFO 



.DXMISC . SOURCE . SO$CPR 



TM$DOR 



. TSKMGR . SOURCE . TM$DOR 



TM$OPN 



. TSKMGR . SOURCE . TM$OPN 



Branch to system overlay. A 
system overlay calls this 
routine to branch to another 
overlay. If the desired 
overlay is already in memory 
the calling task's TSB is 
modified; otherwise, the TSB 
is queued for OVLDR and the 
task is suspended. 

Relink from system overlay. 
A system overlay calls this 
routine to relink back to the 
last task or overlay that 
performed a link to overlay. 
If the relink is back to a 
task, or back to an overlay 
that is in memory, control is 
transferred immediately. If 
the relink is back to an 
overlay no longer in memory, 
the current task is suspended 
and the TSB is queued for 
SOVLDR. 

Enforce access privileges to 
door of a particular 
structure. The door is 
represented as a queue. If a 
task is accessing a data 
structure, the t^sk wanting 
access is queued and 
suspended. Queued tasks will 
be unsuspended and gain 
access when the current 
accessing task exits the door 
via TM$OPN. 

Opens the door to a 
restricted access structure. 
This routine is called by a 
task to release access to the 
door . The next task in the 
queue is unsuspended and the 
door marked open . 
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Table 9-3 Task Management Routines — Part 3 of 5 



Routine 



TM$CLK 



Source Module Pathname 
.TSKMGR . SOURCE . TM$CLK 



TRAPRT 



. TSKMGR . SOURCE . TM$ RTN 



XOPRT1 



. TSKMGR . SOURCE . TM$ RTN 



X0PRT1A 



. TSKMGR . SOURCE . TM$RTN 



SCHRET 
SCHRETA 



X0PRT2 , 
X0PRT3 



. TSKMGR . SOURCE . TM$ RTN 
. TSKMGR . SOURCE . TM$RTN 



. TSKMGR . SOURCE . TMRTN 
. TSKMGR. SOURCE . TMRTN 



Descript ion 

Clock interrupt handler. 

Resets the timer interrupt, 
updates the second counter, 
clock unit counter and time 
slice counter. 

Return point from all 

interrupt processors. 

Returns control to the 

interrupted task (if its time 
slice has not expired), XOP, 
or other interrupt processor. 

First return from XOP 

processors. Returns control 
to the executing task if its 
time slice has not expired. 
Otherwise, it saves the state 
of the executing task and 
recurns control to the 

scheduler. 

X0PRT1A is an alternate entrj 
point to X0PRT1. Upon' 

entering X0PRT1A, the current 
map file (CURMAP) is force- 
switched to the Scheduler map 
file (CURMAP = MAPSHD) . Then 
the X0PRT1 entry point is 
branched to. The alternate 
entry point is required for a 
user SVC exit. 

Return to scheduler by force. 
This routine is an alternate 
entry point to SCHRET for 
user SVC exits. SCHRETA 

branches to SCHRET. 

Return points from XOP 

processors that want the 

calling task suspended. Task 

execution is halted and 

control returns to the 
scheduler. 
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Table 9-3 Task Management Routines — Part 4 of 5 



Routine 

X0PRT2A, 
X0PRT3A 



Source M odule Pathname 

. TSKMGR . SOURCE . TMRTN 
. TSKMGR . SOURCE . TMRTN 



TM$DPR 



. TSKMGR . SOURCE . TM$DPR 



TOLLNK 



.TSKMGR . SOURCE . TM$TOL 



De scription 

Alternate return points from 
XOP processors that want the 
calling task suspended. Task 
execution is halted, the 
program branches to X0PRT2 or 
X0PRT3, which then transfers 
control to the scheduler. 
The alternate points are 
necessary in user SVC 
applications. 

Dynamic task priority 
routine. The Device Driver 
Task calls this routine to 
adjust the priority of a task 
installed with dynamic 
priority according to the 
type of I/O it is performing. 

Links a block of memory onto 
the head of the time ordered 
list (TOL) . 



TOLDEL 



. TSKMGR . SOURCE . TM$TOL 



Delinks the specified block 
of memory from the time 
ordered list. 



TOLTDL 



. TSKMGR . SOURCE . TM$TOL 



Delinks the task segment of 
the specified task from the 
TOL. 



TOLTLK 



.TSKMGR . SOURCE . TM$TOL 



Links the task 
specified task 
of the TOL. 



segment of the 
onto the head 



TOLTSG 



. TSKMGR . SOURCE . TM$TOL 



Calculates the beet address 
at the start of the task 
segment of the specified 
task. 



TMALPR 



. TSKMGR . SOURCE . TMALPR 



Allocates memory for a 

procedure. The procedure can 
be in memory already, on a 
program file, or on the roll 
file. The task loader 

(TMDR) calls this routine. 
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Table 9-3 Task Management Routines — Part 5 of 5 
Routine Sour ce Modul e Pathnam e Description 



TMIMAG 



.TSKMGR. SOURCE . TMIMAG 



TMLDPR 



. TSKMGR . SOURCE . TMLDPR 



TMLDTK 



.TSKMGR . SOURCE . TMLDTK 



TMRDAL 



. TSKMGR . SOURCE . TMRDAL 



TMRDDL 



. TSKMGR . SOURCE . TMRDLL 



RSET12 



.TSKMGR. SOURCE. TM$ INT 



Loads the program segment 
from an image file. Loads 
either a task or procedure 
from a program file or the 
roll file. TMLDTK and TMLDPR 
call this routine. 

Load a procedure from disk, 
either from a program file or 
the roll file. The task 
loader (TMDR) calls this 
routine. 

Load a task segment from 
disk, either from a program 
file or the roll file. The 
task loader (TMDR) calls 
this routine. 

Allocates space in the roll 
file. The allocation 
information is set up in tha 
TSB or PSB of the segmeni 
being rolled. The TSB or PSB 
is linked onto the roll 
directory list. The task 
loader (TMDR) , and memory 
management call this routine. 

Delinks the specified segment 
from the roll directory list, 
causing the space occupied by 
the rolled segment to become 
available. 

Clears the Protection, 
Overflow, and WCS flags in 
the status register. This 
must be called whenever 
entering map from an INT or 
XOP. 
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9.5 MEMORY MANAGER 

Memory management routines perform such functions as allocating 
memory, releasing memory, and rolling out tasks, procedures and 
buffers. A special connection of routines, called buffer 
management, allocates, deallocates, reads, and writes file I/O 
buffers. Table 9-4 shows the major memory management routines. 
Table 9-5 shows the buffer management routines, which file 
management usually calls. 



Table 9-4 Memory Management Routines — Part 1 of 2 



Routine 
MM$GSA 



Source Module Pathnam e 
. MEMMGR . SOURCE .MM$MGR 



MM$RSA 



. MEMMGR . SOURCE . MM$MGR 



MM$GUA 



. MEMMGR . SOURCE .MM$MGR 



MM$RUA 



. MEMMGR . SOURCE .MM$MGR 



MM$GSO 



.MEMMGR . SOURCE ,MM$MGR 



Description 

Get system table area. 
Searches the free system area 
list for a block of the 
specified length and tries to 
allocate it. 

Releases system table area. 
Releases the specified block 
of system area, and places it 
on the free list. The block 
is consolidated with 
neighboring blocks if 
possible. 

Gets user area. Searches the 
free user memory (all memory 
beyond DX10) list for a block 
of the specified length and 
tries to allocate it. 

Releases user area. Links 
the specified block of user 
memory onto the free list and 
tries to consolidate it with 
neighboring blocks. 

Gets system table area, 
clears it to zero. This 
routine calls MM$GSA, then 
clears the allocated block 
(if successful) to zero. 
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Table 9-4 Memory Management Routines — Part 2 of 2 



Routine Source Module P athname 
MM$FND .MEMMGR. SOURCE. MM$FND 



Descript ion 

Finds user memory. All 
routines that need a block of 
user memory call this 
routine. TM$DOR and TM$OPN 
restrict entry to the routine 
to serial access. MM$SCN 
first checks free memory, 
then scans the TOL for 
rollable blocks. If a 
rollable block is available, 
MM$SCN rolls it. 



MM$SCN 



. MEMMGR . SOURCE . MM $ SCN 



MM$ROL 



.MEMMGR. SOURCE. MM$ROL 



Scans the TOL for a rollable 
block. MM$FND calls this 
routine to get a rollable 
block of memory if there is 
not a large enough block of 
free memory. Rollable blocks 
may be task, procedure or 
Luffer memory. 



lure 

;1 



Roll a task or procedure 
segment to the roil fij 
This routine rolls a block 
disk, assuming that roll file 
space is already allocated. 
Calls BM$MAP and FM$WTM. 



MM$RLM 



.MEMMGR . SOURCE .MM$TSK 



Release task memory routine. 
Delinks the task memory of 
the specified task from the 
TOL and releases it. If 
there are attached 
procedures, their attached 
task counts are decremented. 
If the count for a procedure 
goes to zero, its memory and 
PSB are released. 



RELPSB 



.MEMMGR. SOURCE. MM$TSK 



Releases the specified PSB 
and procedure memory. 



MM$TSB 



.MEMMGR. SOURCE .MM$TSK 



Release TSB and memory of a 
task suspended awaiting queue 
input. This routine searches 
the TSB list for a suspended 
queue serving task. If it 
finds one, it releases the 
task's memory and TSB. 
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Table 9-5 Buffer Management Routines — Part 1 of 3 



Routine 



Source Module Pathname 



Description 



BM$RD 



. MEMGR . SOURCE . BM$ RD 



BM$NEW 



.MEMMGR . SOURCE . BM$ RD 



Finds a particular file 
blocking buffer (equal to the 
file physical record) and 
maps it into the calling task 
(usually file management) . 
If the buffer is in memory, 
BM$RD delinks it from the TOL 
and maps it in. Otherwise, 
it allocates memory, reads 
the correct file physical 
record, then maps it in. 

Same as BM$RD except that it 
does not read file records. 
3M$NEW is used to avoid 
reading a sequential file 
record when preparing to 
write it. 



BM$CLO 



.MEMMGR . SOURCE . BM$CLO 



Closes files. This routine 
writes all modified blocks of 
the file for a given LUNO 
(LDT) that are still in 
memory. The blocks remain on 
the TOL until MM$FND needs 
them. 



BM$FLS 



, MEMMGR . SOURCE . BM$CLO 



Plushes blocks. Returns all 
memory occupied by buffers 
for the specified file. 
Modified buffers are written 
to the file before being 
released. Memory resident 

buffers are marked empty and 
left on the TOL. 
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Table 9-5 Buffer Management Routines — Part 2 of 3 



Routine Source Module Pathname 



BM$SCH .MEMMGR. SOURCE. BM$CLO 



Description 



Searches for a 
buffer on the 
search can be res 
the following 
criteria: modi 
unmodified buffer 
LDT address, mod if 
with equal LDT 
modified buffer 
FCB address. 



particular 

TOL. The 

trie ted by 

buffer 

fied or 

with equal 

ied buffer 

address, or 

with equal 



BM$UPD 



.MEMMGR . SOURCE . BM$CLO 



BM$MAP 



BM$MPB 



. MEMMGR . SOURCE . BM$MAP 



. MEMMGR . SOURCE . BM$MAP 



BM$RDM 



. MEMMGR . SOURCE . BM$ RDU 



BM$W 



.MEMMGR . SOURCE . BM$W 



Updates file. This routine 
calls BM$SCH to find a buffer 
on the TOL according to the 
desired criteria. If the 
buffer is modified, it is 
written to the file. 

Maps the specified number of 
bytes from the specified 
task's memory into the 
calling task. 

Maps the specified number or 
bytes from general memory 
into the calling task. This 
routine is given a beet 
address that begins the area 
to be mapped. 

Reads and updates a buffer. 
This routine calls BM$RD to 
get the specified file 
buffer. If the buffer has 
been modified, it is written 
to the file. 

Writes a buffer. This 
routine writes the specified 
buffer, which is mapped into 
the calling task, to the 
specified physical record of 
the file (the destination 
address need not be the same 
as the source file record 
from which BM$W read the 
buffer) . 
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Table 9-5 Buffer Management Routines — Part 3 of 3 
Routine Source Module Pathname Description 



BM$MPK 



BM$IOW 



•MEMMGR . SOURCE . BM$MAP 



.MEMMGR . SOURCE . BM$W 



BM$IOR 



.MEMMGR . SOURCE . BM$W 



BM$LNK 
BM$DEL 
BM$REL 



.MEMMGR . SOURCE . BM$W 



.MEMMGR. SOURCE. BM$W 



. MEMMGR . SOURCE . BM$REL 



BM$RMD 



BM$TRM 



•MEMMGR . SOURCE . BM$REL 



.MEMMGR . SOURCE . BM$REL 



BM$WRN 



.MEMMGR . SOURCE . BM$RDU 



Checks a mapped segment for 
possible write protection 
violation. 

Sets up the I/O call block to 
write the specified buffer to 
the specified record in the 
file. After building the 
call block, it calls FM$IO to 
perform the I/O. 

Sets up the I/O call block to 
read the specified buffer 
from the specified record on 
the file. Calls FM$IO to 
perform the I/O. 

Links the specified buffer 
onto the TOL. 



Delinks the specified 
from the TOL. 



buffer 



Releases a buffer, to buffer 
management. Unmaps a buffer 
from the calling task and 
links it onto the TOL. It 
writes modified buffers to 
the file. 

This routine is the same as 
BM$REL, except it presets the 
buffer's modified flag, 
forcing a write to the file. 

Trims a buffer from memory. 
This routine releases the 
specified buffer to user 
memory. If the buffer has 
been modified, it is first 
written to the file. 

Writes a buffer and renames 
it. Calls BM$W to write the 
specified buffer, then 
modifies the buffer overhead 
to make the buffer correspond 
to the destination file 
record. 
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9.6 DISK MANAGER 

The disk manager consists of a memory resident, queue-serving 
task and several system overlays. The queue server is the main 
driver. It decodes the buffered SVC opcode and links to the 
correct processor (which is a system overlay) for that opcode. 
The disk management opcodes include: 

* — deallocate a block 

* 1 — allocate all of the requested amount 

* 2 — allocate as much of the requested amount as 

possible 

* 3 — allocate as much as possible at the address 

requested or fail. 

Table 9-6 shows the major routines included in disk management. 
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Table 9-6 Disk Management Routines — Part 1 of 2 
Routine Source M odule Pathname Description 



DM$PC 



DMALLC 



.DSCMGR . SOURCE . DM$TSK 



. DSCMGR . SOURCE . DMALLC 



DMDALC 



. DSCMGR . SOURCE . DMDALC 



ADJALC 



. DSCMGR . SOURCE . ADJALC 



ALCSCN 



. DSCMGR . SOURCE . ALCSCN 



CHGMAP 



, DSCMGR . SOURCE . CHGMAP 



Queue-serving main driver for 
disk management. 

Disk allocation main driver. 
This routine processes all of 
the allocation opcodes. It 
converts the requested number 
of file blocks (physical 
records) to a number of ADUs, 
then attempts to allocate 
according to the restrictions 
implied by the opcode. 

Deallocates disk space. This 
routine deallocates the 
specified ADUs by resetting 
the bits in the correct 
partial bit maps. 

Adjusts allocation count by 
computing the number of ADUs 
in a given block of 
contiguous free ADUs for 
allocating file physical 
records of a given ADU size. 

Scans allocation bit map. 
This routine contains two bit 
map scans. The first scans a 
partial bit map for a 
particular allocation 
placement (allocation must 
start at particular ADU) . 
The second, a first-fit scan, 
starts with the first partial 
bit map and searches for a 
large enough block of free 
ADUs. 

Changes the disk allocation 
bit map by setting or 
resetting bits in the disk 
resident bit map to reflect 
the newly completed 
allocation or deallocation 
operation. This routine is 
the common exit path from 
DMALLC and DMDALC. 
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Table 9-6 Disk Management Routines — Part 2 of 2 



Routine 



DM$TBL 



EXTEND 
MAPPBM 



Source Module Pathname 



Description 



.DSCMGR. SOURCE. DM$TBL Builds the disk management 

table by scanning the partial 
bit map currently buffered in 
memory, and filling in the 
disk management table (DMT) 
entries particular to that 
bit map. 



.DSCMGR . SOURCE . EXTEND 



.DSCMGR . SOURCE .MAPPBM 



Extends an allocation across 
partial bit map boundaries. 

Maps a partial bit map by 
reading or writing the 
specified partial bit map 
from or to the disk. 



RDPBM 



.DSCMGR . SOURCE . RDPBM 



WRTPBM 



SCNBIT 



.DSCMGR. SOURCE. WRTPBM 



, DSCMGR . SOURCE . SCNB IT 



SETBIT 



, DSCMGR . SOURCE . SETB IT 



WCHPBM 



. DSCMGR . SOURCE . WCHPBM 



Read partial bit map. This 
routine reads the specified 
partial bit map from the 
specified disk to the 
specified buffer. 



I 



Writes the buffered parti 
bit map to the correct sector 
on the specified disk. 

Scans for a bit of the 
opposite state. Scans in a 
buffered partial bit map from 
the specified bit position 
until it finds a bit of the 
opposite state. 

Sets bits to the given state. 
This routine sets the 
specified number of bits in a 
bit map, starting at the 
specified bit position, to 
the specified state (0 or 1) . 

Calculates a partial bit map 
number and bit position from 
the specified ADU number. 
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9.7 DEVICE I/O PROCESSING 

In addition to the DX10 I/O supervisor, several other routines 
process device I/O calls, such as the device driver routine 
(DDT) , the device service routines (DSRs) , and several common 
routines. Table 9-7 shows the major routines involved in 
processing device I/O. 

Table 9-7 Device I/O Processing Routines 



Routine 



Source Module Pathname 



Description 



DXIOS 



.DXIO . SOURCE .DXIOS 



DX10 I/O supervisor. DXIOS 
processes SVC code 0. It 
preprocesses calls for device 
I/O, file I/O, and file 
utility services, by 
buffering the call block and 
queueing it for the 
appropriate queue server or 
DSR. It also processes all 
I/O to the DUMY device. 



DDT 



, DXIO. SOURCE. DDT 



Device driver. The scheduler 
calls- DDT to initiate device 
I/O, start the DSRs, and 
perform end-of-record 

processing (unbuffering data 
to tasks performing device 
I/O) . 



TMOUT 



.DXIO. SOURCE. DSRTMX 



Device time out check. The 
scheduler calls this routine 
after a system time unit 
elapses. It scans the PDT 
list for a device with a 
time-out error, or if the re- 
en ter-me flag in the PDT is 
set. If the re-en ter-me flag 
is set, TMOUT passes control 
to the DSR. If a device has 
a time-out error , TMOUT 
aborts the I/O. 



FSTXFR 



.DXIO . SOURCE . FSXTXFR 



Tests a file I/O request, 
.DXIO. SOURCE. FSTXFR, to see 
if a "fast transfer" is 
possible. 
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Table 9-8 shows the DSRs included with DX10. Not° that 
source modules for all DSRs are cataloged under the libr' 
.DEVDSR. SOURCE on the disk. 

Table 9-8 Device Service Routines 

Source Module 



t 



Routine Device Served 

CAS733* Cassette units on a 733ASR. 

CRDSR 804 card reader. 

DDIOSR Direct disk I/O. 

DSR911 911 VDT. 

DSR913 913 VDT. 

DSR940 940 EVT. 

DSR979 979 magnetic tape drive. 

DSRKSR* 733 KSR and 743 KSR. 

FPYDSR FD800 diskette. 

LPDSR 306, 588, 810, 2230 and 2260 

line printers. 

DSR820 820 keyboard device. 

DSRTPD Teleprinter devices 



Name 

.CAS733 

.CRDSR 

.DDIOSR 

.DSR911 

.DSR913 

.DSR940 

.DSR979 

.DSRKSR 

.FPYDSR 

.LPDSR 

.DSR820 
.DSRTPD 
.COMISR 
.TTYISR 
. TPDCOM 



* Note: CAS733 and DSRKSR are linked to form DSR73 3 for 
the 733 ASR. 



The source module .DXIO. SOURCE. IOCOMX contains several routines 
commonly used by DSRs. These are: 

Routine Function 

* BZYCHK Sees if the device is busy. 

* SETWPS Sets up an interrupt mask and workspace. 

* ENDRCD Activates the end-of-record routine 

(part of DDT) . 

* XFERM Puts the format (direct disk I/O) data in 

buffer. 

* GTADDR Calculates a 20-bit absolute address from a 

16-bit mapped address (used by DSRs for TILINE 
devices .) 

* MAPCHK Verifies that the specified address 

is mapped into a user's space. 
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Routine 


* 


BUFCHK 


* 


BRCALL 


* 


BRCALT 


* 


JMCALL 


* 


JMCALT 


* 


SCNPDT 



PUTEBP 

PUTCBF 
GETC 
KEYFUN 
TILERR 

ASCCHK 



Function 

Verifies that a buffer is mapped into a single 
base/limit register pair. 

Branch table call. 

Alternate branch table call. 

Jump table call. 

Alternate jump table call. 

Scans the PDT list, and enters the power-up 
routine for each device. 

Puts a character in the event character 

buffer) 

(for keyboard DSRs) . 

Puts a character in the character queue 
(for keyboard DSRs) . 

Gets a character from the event buffer or 
character queue (for keyboard DSRs) . 

Recognizes HOLD, ABORT, or BID keys from a 
keyboard. 

Moves the TILINE image to the system log 
buffer in the PDT extension for TILINE devices 
(used by disk and magnetic tape DSRs) . 

Compares an ASCII character to a table of 

characters and transfers control to the 

address 

associated with the matched character. 



9.8 FILE UTILITY ROUTINES 

DXIOS queues file utility SVCs for the file utility task, FUTIL 
(task >0B on the system program file) . FUTIL consists of a main 
driver, FU$, and several routines to process the different file 
utility opcodes. It also contains two conversion routines, LC$ 
and FC$, which convert the still supported librarian and FUR cali 
blocks to DX10 3.0 file utility call blocks. 

Table 9-9 shows the major file utility routines that make up the 
file utility task, FUTIL. All utility source modules are 
cataloged under the library .FUTIL. SOURCE on the source disk. 
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Table 9-9 File Utility Routines — Part 1 of 5 



Routine 



FU$ 



Source M odul e Pa thname 
.FU$ 



De scription 

Drives and acts as queue 
server for file utility 
requests. Decodes file 
utility opcode and branches 
to the correct processor. If 
the opcode is FUR or 
librarian, branches to FC$ or 
LC$, respectively. 



FC$ 



,FC$ 



Converts FUR call to a new 
call block. Converts the 
call, calls UC$ to execute 
it, . calls CLEAN to unbuffer 
the call, then returns to 
FU$. 



LC$ 



,LC$ 



Converts librarian calls to a 
new call block. Converts the 
call, processes it, calls 
CLEAN to unbuffer the call 
block, then returns to FU$. 



UC$ 



,FU$ 



AA$ 



,AA$ 



Processes normal uti% / 
calls. Checks for bad 
opcodes, looks up the correct 
processor for the given 
opcode (table is in FU$ 
also) , and branches to that 
processor . The processor 
returns to UC$, which returns 
to the caller (either FU$ , 
LC$, or FC$) . 

Processes the Add Alias 
opcode. Adds an alias to an 
existing file. The file must 
have a LUNO previously 
assigned to it. AA$ returns 
to the calling task (UC$) . 



I$ADR 



.AA$ 



Initializes alias descriptor 
record. Initializes a 
buffered ADR (see section on 

disk data structures) and 
then returns to AA$ . 
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Table 9-9 File Utility Routines — Part 2 of 5 



Routine 
AL$ 



Source Module Pathname 
.AL$ 



CF$ 



.CF$ 



DP$ 



.DP$ 



RF$ 



.RF$ 



RL$ 



,RL$ 



RL$LUN 



,RL$ 



De scriptio n 

Processes the Assign LUNO 
opcode. Assigns a LUNO to 
either a file, a device, or a 
temporary file. It also 
builds the necessary FCB/LDT 
tree in the system table 
area. 

Processes the Create File 
opcode. Creates a file, 
including an FDR on disk, 
disk allocation for the file, 
and an FCB in memory. 

Processes the Delete Protect 
opcode. Sets the delete 
protect flag bit in both the 
FCB and the FDR (on disk) for 
the specified file. 

Processes the Rename File 
opcode. Moves the existing 
FDR to the destination 
directory and releases the 
old FDR directory entry. If 
an existing file has the new 
pathname, the renamed file 
replaces it. 

Processes the Release LUNO 

opcode. Sets up registers 

using values from the 

buffered call block, calls 
RL$LUN to release the LUNO, 

then returns to the calling 
routine. 

Internal entry point to 
release LUNO opcode 
processor. RL$LUN calls 
LDTSCH to find the LDT for 
the specified LUNO. Delinks 
the LDT from all chains, and 
flushes (releases) any file 
buffers associated with the 
released LUNO. The LDT is 
released to system table 
area. 
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* 

Routine Source Modul e Pathname Description 

SF$ ,SF$ Processes the Set Forced 

Write Flag opcode. Sets the 
forced write flag in the 
specified LDT to the 

specified state. 

UP$ .UP$ Processes the Unprotect File 

opcode. Reads the FDR for 
the specified file from its 
parent directory, resets the 
protection flags in the FDR 
to zero, and rewrites the FDR 
back to the directory. 

VP$ .VP$ Processes the Verify Pathname 

opcode. Checks a pathname 
for valid syntax, and then 
tries to find the file. If 
the file exists, VP$ returns 
relevant information. 

WP$ .WP$ Processes the Write Protect 

opcode. Sets the writes 

protect bit in the FDR fB, 
the specified file. . 

DA$ .DA$ * Processes the Delete Alias 

opcode. Delinks the alias 
descriptor record (ADR) for 
the specified alias from the 
alias list in the directory 
file (see the section on disk 
data structures) . 

DF$ .DF$ Processes the Delete File 

opcode. Releases all primary 
and secondary file 
allocations on the disk, and 
releases all directory 

entries (FDRs and ADRs) . 

AL$PNC .AL$ Assigns a LUNO to a pathname 

component. Returns the FCB 
address for the specified 
pathname component. If no 
FCB exists, AL$PNC builds one 
and adds it to the FCB/LDT 
tree. 
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Table 9-9 File Utility Routines — Part 4 of 5 
Routine Source Module Pathname Description 



T$FILE 



.AL$ 



T$ADD 
GENLUN 

DEVSCH 

VOLSCH 



.AL$ 
,AL$ 

.AL$ 

.AL$ 



AL$DEV 



AL$FIL 



AL$PAR 



B$FDR 



F$INIT 



,AL$ 



,AL$ 



.AL$ 



.CF$ 



.CF$ 



Assign a LUNO to a temporary 
file. Generates a unique 
pathname for the temporary 
file, then calls AL$ to 
assign the LUNO to it. 



Adds a new FCB 
FCB/LDT tree. 



node to the 



Generates a unique LUNO. 
Searches a given LDT list and 
returns a LUNO not currently 
existing in the list. 

Searches the PDT list for 
device name. If it finds the 
desired device, it returns 
the PDT address. 

Searches the volume tables 

for a volume name. If the 
specified volume is 

installed, the routine 
returns the PDT address of 

the drive on which it is 
installed. 

Assigns a LUNO to a device. 
Searches the PDT list for the 
desired device and assigns a 
LUNO to it. 

Assigns LUNO to a file. Gets 
the system table area and 
builds an LDT for a LUNO to 
assign to a file. 

Assigns a LUNO to a parent. 

Assigns LUNO >CA to the 

parent directory file of the 
specified file. 

Builds a file descriptor 
record and writes it to the 
specified directory record. 



Initializes a file 
its file type. 



based on 
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Table 9-9 File Utility Routines — Part 5 of 5 



Routine 



C$DFLT 



CRBLK 



A$BLK 



Source Modu le Pathname 
.CF$ 



.CF$ 



.CF$ 



R$DSC 



.DF$ 



Descriptio n 

Computes the file 
parameter defaults, 
file type. 



creation 
based on 



Computes the number of file 
physical records required for 
a file based on file type and 
specified initial allocation. 

Allocates the specified 
number of physical records on 
the disk. Calls the disk 
manager to allocate the 
required disk space. 

Releases disk space. Calls 
the disk manager to release 
the primary file allocation 
and all secondary 
allocations. 



R$FDR 



.DF$ 



Releases all file 
records (FDRs) in 

directory for the file 
released. 



descriptor 



bei 



RSALS 



FLLRMV 



,DF$ 



,RL$ 



CLEAN 



,FU$ 



Release aliases. Releases 

all ADR entries in the 
directory for aliases of the 
file being deleted. 

Removes and cleans up file 
LDT. Delinks a file LDT from 
all chains. If the file to 
which the LDT was assigned 
has no more LUNOs assigned 
and no descendants, FLLRMV 
releases the file's FCB. 

Calls TMQUE to queue the 
buffered call block for the 
SVC clean up task, SVCCLN. 
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The file .FUTIL. SOURCE. US$ contains many routines commonly used 
by the file utility processors. These included: 

* LDTSCH — Searches the LDT tree at the specified level 

(task, station, global) for the specified LDT. 

* FNDLUN — Finds the specified LDT. (Not affected by leve.) 

* LDTRMV — Removes the specified LDT from all chains. 

* LDTENT — Enters the specified LDT in the LDT tree. 

* HASH — Computes a hash key value for the specified 

pathname component. 

* LOOKUP — Looks up the specified file by name. 

* I$BLK — Initializes the file blocking buffer. 

* G$REC — Transfers the specified directory record to 

the caller's buffer. 

* FILE10 — Performs all disk I/O for FUTIL. 

* T$CLEN — Cleans up the FCB tree (releases all unnecessay 

FDBs on the upward path from a single leaf nod) . 

* FDRFCB — Translates a buffered FDR and associated block 

into an FCB. 



9.9 FILE MANAGER 

File management under DX10 consists of a pool of memory resident, 
queue serving tasks and four system overlays. The main driver of 
each task is a routine called FM$TSK. This routine is activated 
whenever the I/O supervisor, DXIOS, places an entry on its queue. 
FM$TSK dequeues each entry and passes control to the correct 
processor for the specified I/O opcode. The processor returns to 
FM$TSK, which unbuffers the I/O call block, reactivates the 
calling task, and gets the next entry on the queue. FM$TSK 
issues SVC code >24 when its queue is empty. 
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Table 9-10 shows the major routines that process file I/O calls. 
All source modules are in directory .FILMGR. SOURCE. 

Table 9-10 File I/O Processors — Part 1 of 3 

Source Module 



Routine Description Overlay 

FM$TSK Main driver of file manager. N 
Looks up the opcode in the 
table, then branches to the 
correct processor. 

FMOPEN Open File processor . Checks N 
access privileges for conflicts. 

FMCLOS Close File processor . Updates N 

or file buffers to disk, and 
FMCLUN unlocks locked records. 

FMCLEF Close File with EOF. Writes Y 
end-of-file, then calls FMCLOS. 

FMOPRW Open and Rewind File processor. Y 
Calls FMOPEN, then FMRWND. 

FMRDST Read File Status processor . Y 
Calls BM$MAP to map in user 
buffer, then writes file 
characteristics in buffer. 

FMFBSP Forward/Backward Space processor. Y 
Calls FBSP to reset LDT pointers. 



Name 
.FM$TSK 

. FMOPEN 
.FMCLOS 

.FMCLEF 
.FMOPRW 
.FMRDST 

•FMFMBSP 



9-28 



939153-9701 



System Design Document 



Description of DX10 Routines 



Figure 9-10 File I/O Processocs — Part 2 of 3 



Routine Desc r iptio n Overlay 

FMREAD Read ASCII and Read Direct N 
processor. Calls BM$MAP to 
map in user buffer, then calls 
BM$RD (blocked file) or PM$I/0 
(unblocked) to get proper 
physical record. Transfers the 
proper logical record to a user 
buffer and releases the file 
buffer (if the file is blocked) . 



Source Module 
Name 



.FMREAD 



FMWRIT Write ASCII and Write Direct 

processor. Calls BM$MAP to map 
in the user buffer, then gets 
the proper physical record 
through BM$RD (blocked file) . 
New logical record transferred 
(via FM$IO if unblocked) . 
The buffer (if any) is 
released. 



N 



•FMWRIT 



FMWEOF Write End-of-File processor. 

Writes an EOF (zero length) 
record to a sequential file. 
EOFs to relative record files 
are ignored. 

FMRWND Rewind File processor. Resets 
LDT pointers to show that the 
file is rewound (before the 
first file record) . 



•FMWEOF 



.FMOPRW 



FMRWRT Rewrite Record processor . 
Backs up one record on a 
sequential or relative record 
file and writes the user's 
buffer to that record (calls 
FMWRIT to write) . 



.FMRWRT 
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Figure 9-10 File I/O Processors — Part 3 of 3 



Routine Description Overlay 

FMACES Modify Access Privileges N 

processor . Checks for access 
conflicts between different 
users of a file, and if none 
exist, modifies LDT flags to 
reflect new privileges. 

FMOPXT Open Extend processor. Calls Y 
FMOPEN to open the file, sets 
LDT pointers to end-of-medium, 
then backspaces over any EOFs 
at the end of the file. 

FMOPUB Open for Unblocked I/O. Calls Y 
FMOPEN to open the file, then 
sets a flag in the LDT to allow 
unblocked I/O to the file. 

FM$IO File manager disk I/O routine. N 
Maps a file physical record 
number into ADU/sector offset 
disk address and transfers data 
between a user buffer and the 
disk. 



Source Module 
Name 



.FMACES 



.FMOPXT 



.FMOPUB 



.FM$IO 
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9.9.1 Key Indexed Files 

Key indexed file I/O processing is a major part of file 
management. KIF I/O processing routines reside in one memory 
resident linked object module, KIF, and five system overlays. 
Table 9-11 shows the major routines involved in key indexed file 
I/O processing. All source modules are in directory 

.KI FILE. SOURCE. 

Table 9-11 Key Indexed File I/O Processors — Part 1 of 3 

Source Module 



Routine Descripti on 

KI$BEG Key indexed file I/O driver. 

Receives key indexed file I/O 
requests from FM$TSK, decodes 
the opcode, and branches to 
the correct processor. 

OLNO02 Inserts records into key 
indexed files, using the 
primary key. The key is hashed 
to get a block number, and then 
the record is inserted. The key 
is added to the B-tree for a 
primary key. 

OLNO08 Deletes a record from a key 

indexed file, either by key 
value or currency information. 
The record is removed from the 
block and key values from the 
B-trees. 



Overlay 



N 



Name 



.KI$BEG 



.OLNO0 2 



.OLNO08 



KI$BTD Deletes an entry from a B-tree. 
Searches a B-tree for the 
specified key. If it finds the 
key, it deletes the entry. If 
the B-tree entry is a B-tree 
divider (see the section on 
disk organization) , OLNO09 is 
called to delete the entry from 
the next higher node in the 
B-tree. 



N 



.KI$BTD 
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Table 9-11 Key Indexed File I/O Processors — Part 2 of 3 



Routine 
OLNO09 

KI$RR 



KI$SC 



KI$RN 



KI$BIT 



OLNO01 
KI$BTS 



Descript ion Overlay 

Continues the B-tree delete Y 

routine. 

Reads a record from a key n 

indexed file. If no currency 

information is provided, 

searches the B-tree for the 

specified key and sets up 

currency. Calls BM$MAP to map 

in user buffer, reads the 

desired record using the 

currency information, and 

releases the file blocking 

buffer. 

Driver for Set Currency commands. N 
Sets user's currency information 
to point to the data record and 
the B-tree position corresponding 
to the specified key value. 

Read next record. Uses currency N 
information to find the record 
containing the next largest key, 

then calls KI$RD (same as BM$RD) 

to read the record. 

Insert an entry into a B-tree. N 

Inserts a new key value in the 
proper leaf node of the B-tree. 
If the node becomes full, calls 
OLNO01 to split the leaf into 
two new nodes and add an entry 
to the next higher node. 

B-tree split routine. y 

Searches the B-tree for the n 

specified key value. If KI$BTS 
finds the key value, it creates 
a stack that traces the path 
down the B-tree to the correct 
leaf node; otherwise the routine 
finds the leaf node in which the 
key would fit if it existed, and 
still creates the stack. 



Source M odule 
Name 



.OLNO09 



.KI$RR 



,KI$SC 



,KI$RN 



.KI$BIT 



.OLNO01 
.KI$BTS 



9-32 



939153-9701 



System Design Document 



Description of DX10 Routines 



Table 9-11 Key Indexed File I/O Processors — Part 3 of 3 

Source Module 



Routine 



KI$GRF 



OLNO04 



OLNO03 



Descriotion 



Overlay 



Get free block. This routine is N 
used to get an overflow block or 
B-tree block from the free block 
chain. If the last free block is 
returned, another secondary 
allocation is made to the file. 

Open Random and Close opcode Y 
processor . 

Subroutines used by KI$RW Y 

(rewrite) . This overlay contains 
three pieces of code used by KI$RW 
(rewrite) . 



Name 



.KI$GFR 



•OLNO04 



.OLNO03 
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Section 10 
System Command Interpreter 



10.1 GENERAL 

This section describes the routines that make up the System 
Command Interpreter (SCI) task, as well as the data structures 
and files that SCI uses. In this description, SCI is divided 
into four parts: the command interpreter, the background 
resource manager, the background task bidder, and the output 
queuer. The following paragraphs describe the parts of SCI. 



10.2 SYSTEM COMMAND INTERPRETER 

The function of the command interpreter SCI990 is to interpret 
commands entered at a terminal or listed in a sequential file. 
The command language consists of a set of primitive operations, 
whose names start with a period (such as .BID) , and a procedure 
definition and parameter gathering facility that permits you to 
extend the set of commands. 

SCI990 executes in both batch and interactive modes. In 

interactive mode, the command may prompt you for the values of 

command parameters. In batch mode, parameters are specified by 

keyword assignments in the command statement. Except for 

accessing the commands and their parameters, the command 

interpreter is essentially indifferent to the mode of operation. 
This document mentions a mode of operation (Batch, VDT, TTY) only 
when the description does not apply to all modes. 

10.2.1 Structure of SCI 

SCI990 has two functions, parsing and executing commands. The 
parsing function includes: displaying menus and messages, and 
reprompting for invalid input. The execution of a command can be 
performed internally (for primitive operations) or result in 
evaluation of a procedure definition. Figure 10-1 shows the 
generalized flow of control through SCI990. 

The structure of SCI is composed of direct procedure calls. 
Indirect calls (A calls B calls C) are listed in a cross 
referenced table at the end of this section. 
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Figure 10-1 SCI Flow of Control 
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10,2.2 Overlay Strategy 

Two kinds of overlay structures exist for the System Command 
Interpreter (SCI) task: Those designed for use with the .OVLY 
primitive command, and those that are loaded by the Load Overlay 
SVC. The first type, executed by the S$OVLY routine, include the 
Text Editor and the Debugger . Those loaded by the Load Overlay 
SVC include PARSER and secondary overlays of the Debugger. 

The command interpreter itself has two overlays that are part of 
its basic operation. PARSER contains the bulk of the routines 
used for parsing a command, expanding a procedure definition, and 
executing a primitive command. The GETCMD routine loads the 
PARSER overlay as needed. DERROR contains the error formatting 
and display routines (including the English language text for 
messages) and the log- in/log-off routines. The DERROR routines 
are accessed by means of S$OVLY while the PARSER routines are 
accessed by means of a Load Overlay SVC. 

A third overlay, TINFO, is part of SCI990 proper. TINFO contains 
the command processors for the following commands: 

LTS — List Terminal Status 

MTS — Modify Terminal Status 

SBS — Show Background Status 

KBT — Kill Background Task 

MSG — Display Message at Own Terminal 

CM — Create Message 

AUI — Assign User ID 

DUI — Delete User ID 

MUI -- Modify User ID 

LUI — List User IDs 

WAIT — Wait For Background Task To Complete 

A fourth overlay, OUTQUE, contains the command processors for the 
output queuer: 

PF — Print File At Device 

HO — Halt Output At Device 

RO — Resume Output At Device 

KO — Kill Output At Device 

SOS — Show Output Status 

Other overlays support routines for various command processors, 
such as the Text Editor and Debugger. 

The general strategy for partitioning the command interpreter 
between the shared procedure area, SCI, and the PARSER overlay is 
to attempt to keep the size of the shared procedures plus the 
task area plus the largest overlay as small as possible, but to 
make the shared area as large as possible. You can move any of 
the routines in the PARSER overlay into the shared procedure SCI 
if PARSER becomes the largest overlay. However, take care in 
moving routines from SCI to PARSER, since PARSER is only loaded 
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by GETCMD and many of the routines such as PUTLINE and GETFIL ma 
be called when PARSER is not loaded. For example, GETFIL is 
called during error recovery from a procedure expansion, which 
may occur while a user overlay is loaded. 

10.2.3 Data Structures 

The following paragraphs describe the internal data structures 
created and maintained for system use by SCI. 

10.2.3.1 System Communication Area (SCA) . The System 
Communication Area (SCA) is an area of memory that all command 
interpreters, the background resource manager and the background 
request handlers (QBID, OQUEUE) share as a "dirty" procedure. 
The SCA contains a table of global system data, such as global 
LUNOs and task bid IDs, plus a table called an SCA entry for each 
terminal that uses SCI990. 



10.2.3.2 SCA Entry. Each terminal has a 32-byte entry in the 
SCA for communication between the system command interpreter and 
the background resource manager (BRM) . The fields of the SCA 
entry are labeled and defined as follows: 



SCA$TT 


EQU 





Terminal Type 




SCA$TI 


EQU 


1 


Terminal ID 




SCA$DV 


EQU 


2 


Terminal Device 


Name 


SCA$UI 


EQU 


6 


User ID 




SCA$FO 


EQU 


12 


FG 


Opcode 




SCA$BO 


EQU 


13 


BG 


Opcode 




SCA$FE 


EQU 


14 


FG 


Error Code 




SCA$BE 


EQU 


15 


BG 


Error Code 




SCA$FS 


EQU 


16 


FG 


Status 




SCA$BS 


EQU 


17 


BG 


Status 




SCA$FT 


EQU 


18 


FG 


Task ID 




SCA$BT 


EQU 


19 


BG 


Task ID 




SCA$FL 


EQU 


20 


FG 


Task LUNO 




SCA$BL 


EQU 


21 


BG 


Task LUNO 




SCA$FC 


EQU 


22 


FG 


"CODE" Value 




SCA$BC 


EQU 


23 


BG 


"CODE" Value 




SCA$FR 


EQU 


24 


FG 


Return Code 


(CO 


SCA$BR 


EQU 


25 


BG 


Return Code 


(CO 


SCA$FI 


EQU 


26 


FG 


SCI Task ID 




SCA$BI 


EQU 


27 


BG 


SCI Task ID 
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The fields SCA$TT, SCA$FS, and SCA$BS are subdivided as follows: 
SCA$T T (Byte ) Terminal/User T ype Informatio n 

Bit 

1 = Terminal is disabled 

1-3 User privilege code (0-7) 

4-7 Current terminal mode 

= Batch mode 

1 = TTY mode 
F = VDT mode 

Memory images of every user's TCA are maintained on disk in a 
library of user TCA images. During the log-on process, the 
system loads a user's TCA image into the SCI990 task. When the 
TCA is passed from one system task to another, it is transferred 
via a record on a background or foreground TCA file. Figure 10-2 
shows the overall layout of the TCA. 

SCA$FS (Byte 1 6) Foreground Status 

Bit 

1 = Log-on is required 

1-3 Default user privileges 

4-7 Default terminal mode 

= Batch mode 

1 = TTY mode 
F = VDT mode 

SCA$BS (Byte 17) Background Status 

Bit 

1 = BG Task pending 

1 1 = Message pending 

2 1 = BG Task complete 

3 1 = BG Task bid error 
4-7 Reserved 



10.2.3.3 Text String. Strings of characters are uniformly 
represented within SCI990 as a series of bytes and a pointer. 
The first byte, which the pointer addresses and which can be on 
an odd byte address, contains the count of the number of 
characters in the string. The following bytes contain the 
characters. A string with length zero represents the null 
(empty) string. 
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An output buffer for a routine that returns a string valu 
usually must have the buffer capacity in the first byte so that 
no buffer overflows occur. Some examples of string constants and 
buffers follow: 

STR1 BYTE 10 

TEXT 'STRING ONE' 
BUF1 BYTE 31 

BSS 31 

Note that the first (count) byte is not included in the count. 
The count refers to the number of following bytes. 

10.2.3.4 Terminal Communications Area (TCA) . The terminal 
communications area (TCA) has three purposes. First, it contains 
a description of the user currently logged in at the terminal. 
This description includes his user ID, status, encoded passcode, 
and allotted terminal time. Secondly, the TCA contains the name 
correspondence table (NCT) belonging to the user. The NCT 
contains the user defined synonyms and their values. Thirdly, 
the TCA is used to pass information, including parameters, from 
one system task to another. These task parameters are embedded 
in the NCT. Figure 10-2 shows the layout of the TCA. 

Hex. 
Byte 

* * 

>00 | LENGTH OF TCA | 

+ + 

>02 | OFFSET TO TERMINAL STATUS BLOCK j 

+ + 

>04 | RESERVED | 

+ + 

>06 | RESERVED | 

+ . ___+ 

>08 | OFFSET TO NAME CORRESPONDENCE TABLE (NCT) | 

+ + 

>0A | OFFSET TO END OF NCT | 

+ + 



>0C 



TERMINAL STATUS BLOCK 



NAME CORRESPONDENCE TABLE 



Figure 10-2 TCA Layout 
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10.2.3.5 Terminal Status Block (TSB) . The TSB, as shown in 
Figure 10-3, is used to identify the logged-in user to the 
various command processors. The encoded passcode permits 
passcode verification without exposing the actual passcode value. 
The user status information is copied to the terminal SCA entry 
at log-in, and specifies the level of user capabilities in the 
system. The FG task completion code is the medium by which FG 
task completion codes are returned (those tasks executed with 
".BID"). 



Hex. 
Byte 

>00 



>06 




FOREGROUND TASK COMPLETION CODE 



>08 



>0A 



>0C | 



>14 



>18 



>1A 



ENCODED PASSCODE 
USER STATUS 



RESERVED 




USER DESCRIPTION TEXT 



>2A * 

Figure 10-3 Terminal Status Block 



10.2.3.6 Name Correspondence Table (NCT) . The NCT, as shown in 
Figure 10-4, consists of pairs of text strings terminated by a 
zero byte. Each text string is formed from a series of 
characters preceded by the count of the number of characters. A 
length of zero is not permitted. User defined synonvms may 
consist of printable characters only. 
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Positional parameters (elements of the "PARMS" list on a .BTu , 
.QBID, or .OVLY command) are transmitted to the command processor 
program via special entries of the following form: 



Byte 3, 0, 0, Parameter Number 

Byte 15 

Text "DS0 2. SYS. SOURCE" 



Synonym 
Value 



A program completion message (argument R2 of S$STOP) returned bv 
a task executed via a .BID or .QBID command is transmitted back 
to the FG command interpreter as a bogus parameter 0. 



SIZE OF SYN t NAME 



SYNONYN 1 NAME 
TEXT 



SIZE OF SYN 1 VALUE 



SYNONYM 1 VALUE 



SIZE OF SYN 2 NAME 



^ 



(END OF NCT) 



3278142 



Figure 10-4 Name Correspondence Table 



10.2.4 Interfaces 

SCI interfaces to the user, and to various SCI routines, through 
the terminal and several files. The following paragraphs 
describe the interfaces. 



10.2.4.1 Calling Sequence. The calling sequence for SCI990 
depends on the mode of operation. In interactive (VDT or TTY) 
mode, the SCI task is bid by the operating svstem in response to 
the user entering RESET followed by an exclamation mark " !". In 
batch mode, the task is bid by the QBID mechanism (see paragrJf 
10.4) as a result of an XB command. The mode is determinedf| 
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the four bytes passed as parameters of the Bid Task SVC, which 
are formatted as follows: 

* -i * 

| TYPE | STATION ID | 
+ + + 

| RESERVED j 

* * 

The TYPE field is a copy of the SCA$TT (terminal type) field in 
the ter minal SCA entry. The STATION ID is the terminal 
(station) number. In interactive mode, both the type and STN ID 
fields are zero and the information is derived from a SELFID SVC 
and the SCA entry. In batch mode, the fields are (and must be) 
non-zero to distinguish the mode. 

10.2.4.2 Terminal Local File. The terminal local file (TLF) is 
a buffer on disk for lines to be displayed to the user. The 
lines are buffered so that VDT users can scroll back and forth 
through them and so they can be listed together in batch mode. 
The name of the file is determined from the SCI mode and the 
terminal number as follows: 

FOREGROUND: ,S'$FTLF** where ** = terminal number 
BACKGROUND: .S'$BTLF** where ** = terminal number 

The interactive modes of SCI run in the foreground, while the 
batch mode executes in background. 

The TLF is written to by the S$IO routines: S$OPEN, S$WRIT, 
S$WEOL, and S$CLOS. Whenever SCI990 prepares to input a new 
command, the TLF is displayed (TTY, VDT modes) or listed (batch 
mode) by the S$SHOW routine. 

10.2.4.3 System Procedure Library. Commands are mapped into 
procedure file names by concatenating them on the end of the 
current procedure library name. Unless the user overrides the 
default PROC library name with a .USE command, the standard 
system PROC library is used. This directory is named ,S$PROC. 

10.2.4.4 Menu Files. Menus are displayed in VDT mode by 
displaying the contents of a menu file. Menu files are named by 
concatenating the name of the system PROC library, the characters 
n .M$", and the menu name. The default menu file is .S$PROC.M$LC, 
which is also displayed in response to "/LC". 
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10.2.4.5 TCA Library File — .S$TCALIB. The terminal 
communication area (TCA) is described in paragraph 10.2.3.4 A TCA 
image is created for each user when his user ID is assigned. 
This TCA image resides on the TCA library file ,S$TCALIB while 
the user is not logged in. Each record of the TCA library file 
holds exactly one TCA image. The number of the record containing 
the TCA image for a particular user ID is the same as the numeric 
part of the ID. For example, a user ID of "ABC010" uses record 
10 (or >A) or the TCA library file. The numeric parts of user 
IDs must therefore be unique. Since the TCA library is 
implemented as an unblocked, relative record file, DX10 allocates 
records in blocks. Thus it is desirable that the record numbers 
be grouped, preferably by assigning them sequentially starting at 
1. Unneeded user IDs can be deleted and their TCA library 
records reused by assigning the same numeric part of the ID. For 
example, delete user ABC010 and assign user DEF010. 

The TCA library file . S$TCALIB is accessed only during log-in and 
log-out (in the DERROR module) and by the command processors for 
AUI, DUI, LOI, and MUI (in the TINFO module). The byte field 
SCA$L5 in the SCA module defines the globally assigned LUNO used 
for accessing the TCA library file (>C3) . 

10.2.4.6 Foreground TCA File — .S$FGTCA. When a user logs W 
at a terminal, SCI990 reads his TCA image into memory. While tl% 
user is logged in, this TCA image is used by the various command 
processors to maintain his list of synonyms, maintain a history 
of the status of his operations, and transmit parameter values 
and messages between the various components of the SCI system. 
When a command processor is implemented as a task separate from 
SCI990, the TCA image is written to a record of the foreground 
TCA file for the command processor task to read it. Routines 
S$PTCA and S$GTCA put and get the TCA, respectively. The record 
number of TCA file is the same as the terminal number. The 
foreground TCA file, S$FGTCA, is accessed through the global LUNO 
found in byte SCA$L3 of the SCA module. 

10.2.4.7 Background TCA File — .S$BGTCA. The background TCA 
file, .S$BGTCA, is similar to the foreground TCA file. This file 
is used for communication between the batch/background SCI and 
its command processors. In addition, the background TCA file is 
used for passing synonyms and parameters to tasks which are 
executed through QBID. The QBID task "freezes" the foregound TCA 
image on record "I" of the foreground TCA file (where "I" is the 
terminal number) onto record "I" of the background TCA file when 
the background task bid request is made through the background 
request manager. The background TCA file is accessed through the 
global LUNO found in byte SCA$L4 of the SCA module. 
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10.2.5 SVC Overhead Analysis 

The following four subsections detail the use of DX10 SVCs, 
primarily for I/O, which are necessary for the execution of a 
typical .BID or .OVLY program. The .BID and .OVLY cases assume a 
task or overlay which accesses the TCA for parameters or synonyms 
and generates a listing on the terminal local file. An analysis 
is presented in paragraph 10.2.5.5. 



10.2.5.1 .BID SVC Overhead for Foreground SCI990. Table 10-1 
shows the SVC overhead incurred by SCI990 while processing a .BID 
command. In the timing estimates, the Bid Task SVC cost includes 
the overhead for End Task processing. The overlay for the Open- 
Extend of the TLF is assumed to be on disk. 

Table 10-1 .BID SVC Overhead for SCI 



Time 



Disk 



Routine 






SVC 


(Msec) 


Accesses 


XBID 


01 


__ 


Close the terminal 


4.4 





S$PTCA 


00 


— 


Open .S$FGTCA 


4.7 







OC 


-™ 


Write direct, 1 record 


11.4 


1 




01 


— 


Close .S$FGTCA 


5.9 





S$BID 


2B 


— 


Bid Task 


36.2 


2 


S$GTCA 


00 


— 


Open terminal 


4.5 







00 


— 


Open .S$FGTCA 


4.7 







0A 


— 


Read direct, 1 record 


11.3 


1 




01 


— 


Close .S$FGTCA 


5.9 





S$OPEN 


12 


— , 


Open-extend TLF 


25.9 


2 


TOTALS 








119.6 


6 



10.2.5.2 .BID SVC Overhead In The Task Being Bid. Table 10-2 
shows the SVC overhead incurred by a task being bid through .BID. 
In the timing estimates, the (91) LUNO assignment to the TLF 
requires no disk accesses because the SCI task has a previously 
assigned LUNO attached to the file. This also reduces the timing 
from about 42 msec to 17 msec. The (12) open-extend estimate 
assumes that the overlay is in memory and the TLF is empty. If 
it is not empty, the estimate would be (18, 2, 1) . The TLF is 
closed during task termination. The overhead for task 
termination is assumed in the Task Bid in paragraph 10.2.5.1. 
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Table 10-2 Overhead in the Bid Task 



TOTALS 



Time 



70.8 



Disk 



Routine 


SVC 


(Msec) 


Accesses 


S$NEW 


17 — Get Bid Parameters 


.2 





S$GTCA 


00 — Open .S$FGTCA 


4.7 







0A — Read Direct, 1 Record 


11.3 


1 




01 — Close .S$FGTCA 


5.9 





S$OPEN 


91 — Assign LUNO to TLF 


17.0 







12 — Open-Extend TLF 


9.7 





S$PTCA 


00 — Open .S$FGTCA 


4.7 







0C — Write Direct, 1 Record 


11.4 


1 




01 — Close .S$FGTCA 


5.9 






10.2.5.3 .OVLY SVC Overhead for SCI990. Table 10-3 shows the 
overhead incurred by SCI in executing an .OVLY command. Since an 
overlay is part of the SCI task, the TCA is available in memory 
and the TLF is already open. 



Table 10-3 .OVLY SVC Overhead for SCI 

Time 



Routine SVC 

S$OVLY 14 — Load Overlay 



(Msec) 
19.2 



Disk 
Accesses 



iS™ : 0VLY SVC 0verh «a<3 in the Overlay. For overlays, 
S$GTCA and S$RTCA access the TCA directly in memory and require 
D?o °* The TLF is not actua Hy opened and closed by S$OPEN and 
S5CLOS, so the only TLF I/O overhead is in the actual write SVCs, 
which are ignored in this analysis. Therefore, no overhead is 
incurred by the overlay being bid through an .OVLY command. 

10.2.5.5 Analysis. The assumptions made for this analysis are 
neither best nor worst case and are probably typical, it is 
further assumed that the cost of a disk access is approximately 
100 msec for a DS31/32 disk drive and 60 msec for a DS25/50 disk 
drive. The SVC overhead for a typical .BID is then about 986 
msec (114.9 + 70.8=185.7 msec, 6+2=8 disk accesses) . The SVC 
overhead for the same program executed as an .OVLY is then 219 
msec (19.2 msec, 2 disk accesses). The overhead for writiai 
lines to the TLF is the same in both cases and is ignored, as i; 
all other processing done by the program. For short functions, a 
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.BID costs four times as much as an .OVLY in system overhead and 
terminal response time. In both cases, the response time is on 
the order of a second or less. 



10.3 BACKGROUND RESOURCE MANAGER 

The Background Resource Manager (BRM) manages the background 
resources of the DX10 system command interpreter. These 
resources include the background task execution facility (QBID) 
and the output queuer (OQUEUE) . BRM polls the SCA for background 
service requests from user terminals and bids the appropriate 
program to handle the request. It does not service requests 
itself and is not aware of the meaning of the requests it 
manages. Adding background services may be accomplished by 
adding background tasks to the system. 

10.3.1 Structure of BRM 

The BRM program consists of three modules,, a task and two 
procedures. The first procedure is the system communication area 
(SCA) , which contains the SCA entries which are polled for 
service requests. The second procedure is the background 
communication area (BCA) through which BRM communicates with QBID 
and OQUEUE. The task contains the actual BRM code and data. 
Both the SCA and BCA are "dirty" shared procedures. The SCA is 
described in the earlier discussion of SCI990. The BCA is 
described in paragraph 10.3.3. 

10.3.2 Calling Sequence 

The BRM must be placed into execution before any SCI background 
service request is made through the SCA. This is normally done 
by bidding BRM from the DX10 system restart task. BRM then waits 
in a time delay for a service request. 

A service request is made by placing an opcode value in the 
SCASFO (PG SCI opcode) or SCA$BJO (BG SCI opcode) field of a 
terminal's SCA entry and executing an Activate Time Delay Task 
SVC to wake up the BRM. The run ID of the BRM task is 
initialized in byte SCA$L2 of the SCA. The requesting SCI then 
enters a time delay loop waiting for the SCA$FO (or SCA$BO) field 
to clear . 

Background service request opcodes are byte values consisting of 
two hexadecimal digits. The first digit identifies the program 
that processes the request. The second digit specifies a 
particular operation. BRM uses only the first digit to determine 
the task ID to bid. 
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Specific opcode values are documented in the QBID and OQUlL^ 
descriptions (paragraphs 10.4 and 10.5) . 

10.3.3 Background Communications Area (BCA) 

The BCA consists of two parallel vectors, the TASKID and BUSY 
tables, which are used for communication with the background 
request handler tasks. The first digit of a service request 
opcode is used to index these vectors. The TASKID vector maps 
the opcode into a DX10 task bid ID. The BUSY vector informs the 
BRM whether the indicated task/opcode is currently in execution 
or must be bid to handle the request. The BRM sets the busy flag 
when it successfully bids the task. The task resets it when it 
terminates. 

Entry of each vector is meaningless since an opcode field value 
of indicates no request. 



10.4 QUEUED TASK BID HANDLER (QBID) 

QBID supervises the enqueueing and bidding of background tasks. 
In this context, Background (abbreviated BG) means that a task 
execution is to be initiated at a terminal via the .QBID S 
language primitive. Such tasks are then managed by the u( 
indirectly through commands that access the QBID program. 

10.4.1 Structure of QBID 

The QBID program consists of three segments. Two shared "dirty" 
procedures, the SCA and BCA, are used for communication with the 
background resource manager and the command interpreter making a 
QBID service request. These procedures are described in the 
documentation for the background resource manager and SCI. 

The task segment of the QBID program consists of several modules 
which contain the QBID code and data. The code is organized as a 
supervisor and four major components. The supervisor executes 
the four routines BOOKIE, POLLER, BIDDER, and WAITER repeatedly 
until WAITER determines that no work remains. 

The bookkeeper routine BOOKIE keeps track of the status of all 
tasks being managed by QBID. Its principal duties are: 

* Try to remove blocks from blocked tasks 
Remove queue entries of expired tasks 

* Calculate the current level of background task activity 



* 



10-14 939153-9701 



System Design Document System Command Interpreter 



Blocked tasks are those that cannot be bid at a particular time 
but are expected to be bidable later. Examples are tasks that 
are not replicable but are currently in execution. Expired tasks 
are those that have been successfully bid and have subsequently 
terminated. 

The POLLER routine periodically examines the SCA for QBID service 
request opcodes. Opcodes in the range >10 - >1P are handled 
immediately by invoking the appropriate routine: 

Opcode Routine Purpose 

10 BUILDQ Build a queue entry 

11 STATUS Check status of queued task 

12 KILLQT Kill a queued task 

13 DBID Bid task in halted state 

The BIDDER routine attempts to bid tasks waiting on the 
background task queue within the constraints of the sysgen- 
imposed threshold count. Tasks are bid only if the current 
background activity level count is not exceeded. Candidate tasks 
on the queue must not be currently executing or marked as 
blocked. Bid attempts that fail because the specified task is 
not replicable or because the system table area is full cause the 
task to be marked as blocked. 

The WAITER routine decides whether QBID has further work to do. 
If not (if the queue is empty) , it informs the BRM via the BUSY 
vector in the BCA that is terminating and does so. If there is 
more work to do, WAITER executes a time delay SVC and exits. The 
supervisor then repeats the execution of the four primary 
routines. 

Table 10-4 shows the structure of QBID as a table of direct 
subroutine calls. 

Table 10-4 QBID Subroutine Call Table 

Calling Routines 

Routine Called - 

QBID BIDDER, BOOKIE, POLLER, WAITER 

BIDDER 

BOOKIE TSTATE 

POLLER BUILDQ, DBID, KILLQT, STATUS 

WAITER 

BUILDQ TCASVC 

DBID BUILDQ 

KILLQT STATUS 

STATUS TSTATE 

TCASVC 

TSTATE 
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10.4.2 Data Structures 

The following paragraphs describe the data structures used by 
QBID routines. 

10.4.2.1 System Communication Area (SCA) . The SCA is an area of 
memory shared as a "dirty" procedure by all command interpreters, 
the BRM, and the background request handlers (QBID,OQUEUE) . The 
SCA contains a table of global system data, such a global LUNOs 
and task bid IDs, plus a table called an SCA entry for each 
terminal that will use SCI990. The SCA is documented in the 
description of SCI990 (see paragraph 10.2) . 

10.4.2.2 Background Communication Area (BCA) . The BCA consists 
of two parallel vectors, the TASKID and BUSY tables, which are 
used for communications between the BRM, QBID, and OQUEUE. The 
first digit of a service request opcode is used to index these 
vectors. The TASKID vector maps the opcode into a DX10 task bid 
ID. The BUSY vector informs the BRM whether the indicated 
task/opcode is currently in execution or must be bid to handle 
the request. The BRM sets the busy flag when it successfully 
bids the task. QBID resets it when it -terminates. 



10.4.2.3 Task Queue Entry. Each' task to be bid by QBID has an 
associated queue entry, which is created by QBID in its own task 
area. Each queue entry describes a task, information necessary 
to bid the task, and the current execution status. The fields of 
a queue entry are labeled and defined as follows: 

Address of next queue entry 

— QNEXT must be zero — 

Status of queue entry 

Terminal ID 

User ID 

Task bid ID 

LUNO 

Code value 

Task Run ID 

Time place in queue 

Time task was bid 

No. of bytes in a queue entry 



QNEXT , 


EQU 





QSTAT 


EQU 


2 


QTERM 


EQU 


3 


QUSRID 


EQU 


4 


QBTASK 


EQU 


10 


QLUNO 


EQU 


11 


QCODE 


EQU 


12 


QRTASK 


EQU 


13 


QTIME1 


EQU 


14 


QTIME2 

* 


EQU 


18 


QESIZE 


EQU 


22 
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The status byte (QSTAT) is divided as follows: 
Bit 

1 = Task has been bid 

1 1 = Task is blocked (task ID in use) 

2 1 = Task is running 
3-7 Reserved 

10.4.3 Calling Sequence 

QBID Is always bid by the background resource manager (BRM) task 
in response to a background service request from a terminal 
command interpreter (FG or BG) . SCA opcodes in the range 10 
through IF are directed to QBID. The currently defined opcodes 
are: 

10 Enqueue a background task bid (.QBID) 

11 Check status of an enqueued task 

12 Kill an enqueued task 

13 Execute a BG task in debug mode (.DBID) 

Associated with these opcodes are fields within the SCA entry 
that specify parameter values. These are: 

SCA$BC BG "CODE" Value 

SCA$BL BG Program File LUNO 

SCA$BS BG Status 

SCA$BT BG Task ID 

SCA$FE Returned error code (FG) 

SCA$TI Terminal ID 

10.4.4 Files 

The only files accessed by the QBID task are the foreground and 
background TCA files, .S$FGTCA and .S$BGTCA, via the LUNOs 
specified in the SCA. When a task is enqueued for BG execution, 
the FG TCA image for the terminal is copied from the FG TCA file 
to the BG TCA file. The TCA image is a single record in each 
case. The record number is the same as the terminal number. The 
TCA image is "frozen" in this manner so that the parameters 
specified on the corresponding .QBID language primitive will be 
available to the enqueued task when it executes. Also, all 
synonyms defined at the terminal will be available to the task. 

The TCA image is described in detail in the SCI990 discussion 
(see paragraph 10.2) 
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10.4.5 Error Codes 

The following error codes are returned in the SCA$PE field of the 
SCA entry for the terminal making the QBID request. 

Code Meaning 

00 No error — request serviced 

01 Unable to allocate a queue entry block 

02 Unable to access the TCA 

02 BG already pending (should be caught by the 
command interpreter first) 

03 Bid SVC failed for " .DBID" request 
80 Unknown SCA opcode 

FF No queue entry found (Status) 



10.5 QUEUED OUTPUT HANDLER (OQUEUE) 

OQUEUE supervises the enqueuing of files and output to devices 
and of messages to and from terminals. Files are queued up for 
output by name, rather than by copying the named file to a 
spooled data area. Any number of files may be queued for any 
number of devices. OQUEUE also enqueues messages for 
transmission to terminals. 



10.5.1 Structure 

The OQUEUE program is divided into two tasks, OQ$COPY and 0Q$MGR, 
each of which consists of three segments. Both tasks share 
"dirty" procedures, the SCA and BCA which are used for 
communication with the SCI990 task making an OQUEUE service 
request. These procedures are described in the documentation for 
the background resource manager and the command interpreter. 

The task segment of the OQ$MGR program consists of several 
modules. The code is organized as a supervisor and four major 
components. The supervisor executes the three routines POLLER, 
BOOKIE, and WAITER repeatedly until WAITER determines that no 
work remains. 

The POLLER routine periodically examines the SCA for OQUEUE 
service request opcodes. Opcodes in the range >20->2F are 
handled immediately by invoking the appropriate routine: 
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Opcode 


Routine 


20 


BUILDQ 


21 


STATUS 


22 


KILLDV 


23 


HALT IT 


24 


RESUME 


2E 


SMSG 


2F 


RMSG 
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Purpose 

Build a queue entry 
Show output status 
Kill output at a device 
Halt output to a device 
Resume output to a device 
Send a message 
Receive a message 

The bookkeeper routine BOOKIE tracks current I/O and message 
activity, ensuring that each queue entry is ultimately processed. 
BOOKIE calls MBOOKY to check each pending message destination 
against each currently logged-in SCA entry. When a terminal for 
which a message is pending is discovered to be activated, the 
message pending flag in the background status field (SCA$BS) of 
the SCA entry is set. BOOKIE then calls OBOOKY, which attempts 
to assign an output processor to a file queue entry waiting for 
access to an output device, and assigns an OQ$COPY task to each 
device for which output is queued. Thus, queued output may be 
directed to many devices simultaneously. 

OQ$COPY is a replicative task that copies files to a device. The 
file and device must have been assigned global LUNOs prior to 
execution of OQ$COPY. OQ$COPY is bid by the BOOKIE portion of 
OQ$MGR. The Device Status Table (DST) in the BCA contains all 
the information necessary to copy file records to the device. 

The WAITER routine decides whether OQUEUE has further work to do. 
If not, (if the queues are empty) , it informs the BRM via the 
BUSY vector in the VCA that it is terminating and does so. If 
there is more work to do, WAITER executes a time delay SVC and 
exits. The amount of the time delay is determined dynamically by 
WAITER. After the time delay, WAITER exits. The supervisor then 
repeats the execution of the four primary routines. 

Table 10-5 shows the structure of OQUEUE by its subroutine call 
linkages . 
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Table 10-5 OQUEUE Subroutine Call Table 



Calling 
Routine 

OQ$MGR 
BOOKIE 
POLLER 



Routines 
Called 

BOOKIE , POLLER, SLICER, WAITER 
MBOOKY , OBOOKY 

BUILDQ,HALTIT,KILLDV, RESUME, RMSG, 
SMSG, STATUS 



WAITER 

MBOOKY 

OBOOKY 

BUILDQ 

HALTIT 

KILLDV 

RESUME 

RMSG 

SMSG 

STATUS 

WRITER 

GETFET 

GETBLK 

GTCA 

S$PARM 

FINDDV 

OPARMS 

S$SETS 

PTCA 

Q$OPEN 

Q$WRIT 

Q$WEOL 

WRSTAT 

Q$CLOS 

OPENDV 

OPENFL 

COPYFD 

CLOSEF 

CLOSED 

WSTOP 

TCHELP 

CLRBUF 

SVC$R2 

OPN$R2 

SVC$R1 

FORMAT 

WAIT 



GETFET 

GETBLK ,GTCA , S$PARM 

FINDDV, OP ARMS 

FINDDV, OP ARMS 

FINDDV, OP ARMS 

GTCA, S$ SETS, PTCA 

GETBLK ,GTCA, S$PARM 

GTCA,S$PARM,Q$OPEN,Q$WRIT,Q$WEOL, 

WRSTAT, Q$CLOS 

OPENDV , OPENFL , COPYFD , CLOSEF , CLOSED ,WSTOP 



TCHELP 



GTCA.S$PARM 

TCHELP 

CLRBUF 

CLRBUF 
Q$WRIT,Q$WEOL 

SVC$R2,OPN$R2 

SVC$R1 

SVC$R1, FORMAT, SVC$R2,OPN$R2, WAIT 

SVC$R1 

SVCR2,WAIT 



WAIT 

SVC$R2 

WAIT 
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10.5.2 Data Structures 

The internal data structures used by OQUEUE routines 
described in the following paragraphs. 



are 



10.5.2.1 System Communication Area (SCA) . The SCA is an area of 
memory shared (as a "dirty" procedure) by all command 
interpreters, the BRM, and the background request handlers (QBID, 
OQUEUE) . The SCA contains a table of global system data, such as 
global LUNOs and task bid IDs, plus a table called an SCA entry 
for each terminal which may use SCI990 (see paragraph 10.2) . 

10.5.2.2 Background Communication Area (BCA) . The BCA consists 
of two parallel vectors, the TASKID and BUSY tables, which are 
used for communication between the BRM, OBID, and OQUEUE. The 
first digit of a service request opcode is used to index these 
vectors. The TASKID vector maps the opcode in a DX10 task bit 
ID. The BUSY vector informs the BRM whether the indicated 
task/opcode is currently in execution or must be bid to handle 
the request. The BRM sets the busy flag when it successfully 
bids the task. OQUEUE resets it when it terminates. 



10.5.2.3 Output Queue Entry. Each output entry describes a file 
and a device to which the file is to be copied. The fields of 
the output queue entry are labeled and defined as follows: 

Address of next queue entry 

— QNEXT must be zero — 

Status of queue entry 

Terminal ID 

User ID 

Time placed in queue 

Time task was bid 

Max length of message name 

Max length of message user ID 

Actual length of device name 

Actual length of message user ID 

Device access name/message user ID 

Max length of access name 

Max length of message text 

Actual length of access name 

Actual length of message text 

File access name/message text 

Max No. of bytes in a file name 
Max No. of bytes in device name 
QACNM+QASIZE No. of bytes in queue entry 

The status byte (QSTAT) is subdivided as follows: 



QNEXT 


EQU 





QSTAT 


EQU 


2 


QTERM 


EQU 


3 


QUSRID 


EQU 


4 


QTIME1 


EQU 


10 


QTIME2 


EQU 


14 


QDLMAX 


EQU 


18 


QULMAX 


EQU 


18 


QDNLEN 


EQU 


19 


QUILEN 


EQU 


19 


QDVNM 


EQU 


20 


QALMAX 


EQU 


26 


QTLMAX 


EQU 


26 


QANLEN 


EQU 


27 


QMTLEN 


EQU 


27 


QACNM 

* 


EQU 


28 


QASIZE 


EQU 


80 


QDSIZE 


EQU 


6 


QESIZE 


EQU 


QAi 
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Bit 

1 = Output has begun 

1 1 = ANSI Format 

2 1 = I/O completed 
3-7 Reserved 



10.5.2.4 File Environment Table. A file environment table (FET) 
is assigned to each output device for which files are queued. 
The FET contains the data specifying the file and device, a 
workspace, and all data and buffers used by a WRITER routine to 
copy records from the file to the device. The FETs and WRITER 
are analogous to DX10 tasks and a shared procedure. The fields 
of a FET are labeled and defined as follows: 



WFETRO 


EQU 





32 BYTE WORKSPACE 


WNFET 


EQU 


32 


§ NEXT FET IN FET QUEUE 


WPC 


EQU 


34 


@ NEXT ENTRY INTO WRITER 


WQNTRY 


EQU 


36 


§ INPUT FILE QUEUE ENTRY 


WLINES 


EQU 


38 


# LINES LEFT ON PAGE 


WDVTYP 


EQU 


40 


DEVICE TYPE CODE 


WSTAT 


EQU 


41 


STATUS 


WDEVNM 


EQU 


42 


DEVICE NAME 


WSTACK 


EQU 


46 


RETURN STACK 


WPRBI 


EQU 


54 


INPUT PRB 


WPRBO 


EQU 


94 


OUTPUT PRB 


WBUFF1 


EQU 


134 


BUFFER 1 


WFSIZE 


EQU 


WBUFF1+140 


END OF FET 



The FET status byte (WSTAT) is subdivided as follows: 
Bit 

1 = Halt output immediately 

1 1 = Halt output at EOF 

2 1 = Kill output of current file 

3 1 = Kill all output at device 
4-7 Reserved 



10.5.3 Calling Sequence 

OQUEUE is always bid by the background resource manager (BRM) 

task in response to a background service request from a terminal 

command interpreter (FG or BG) . SCA opcodes in the range of >20 

through >2F are directed to OQUEUE. The currently defined 

opcodes are: 



>20 
>21 
>22 
>23 
>24 



Release file to queue 
Show output status 
Kill output to a device 
Halt output to a device 
Resume output to a device 
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>2E Send message 
>2F Receive message 

Associated with these opcodes are fields within the SCA entry 
that specify parameter values. These are: 

SCA$BS BG Status 

SCA$DV Terminal device name 

SCA$FE Returned error code (FG) 

SCA$TI Terminal ID 

SCA$UI User ID 

10.5.4 Files 

OQUEUE uses the TCA file and a listing file, as described below. 

10.5.4.1 TCA File. The foreground or background TCA file record 
corresponding to the number of the terminal making the OQUEUE 
service request is read (by module OQ$TCA) so that the opcode 
handling routines can access the parameters in the NCT. 

The TCA image is described in detail in the documentation for the 
system command interpreter program, SCI990. 

j.0.5.4.2 Listing File. The Show Output Status function has a 
listing file as a parameter. This listing file is normally the 
foreground or background terminal local file (TLF) , at the option 
of the SCI PROC which invokes OQUEUE. The module OQ$TLF includes 
the routines used to write to the listing file. 

10.5.5 Error Codes 

The following error codes are returned in the SCA$FE field of the 
SCA entry for the terminal making the OQUEUE request. 

Code Meaning 

00 No error - request serviced 

01 No queue block available 
80 Unknown SCA opcode 

FA Invalid argument 

FD NCT error (internal) 

FD TLF Error 

FD TCA error 

FF Queue entry not found 
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Appendix A 
System Crash Analysis 



A.l GENERAL 

When the DX10 operating system detects a system failure, it 
displays an error code on the front panel lights and idles the 
CPU, as described in the DX10 Operating System Operations Guide 
(Volume II) . 

If your system uses DX10 release 3.4 or later, it automatically 
dumps memory to the predefined crash file (usually .S$CRASH) on 
disk if the system crashes. However, earlier releases of DX10 
software require that you manually preserve the memory at crash 
time by pressing the HALT and then the RUN buttons on the front 
panel. Once memory is preserved, you must perform an initial 
program load (IPL) , and bid the system command interpreter (SCI) 
as explained in Volume II of the DX10 manuals. At this point, 
you are ready to execute the crash analyzer, ANALZ, using the 
XANAL command . 
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A. 2 OPERATING PROCEDURE 

When you activate ANALZ with the 
appear on your screen. These are: 



XANAL command, five prompts 



CONTROL ACCESS NAME: 



Enter the name of the file or 

device from which ANALZ is to 

receive commands. The default 
is ME. 



LISTING ACCESS NAME: 



Enter the name of the file or 
device to which ANALZ should 
write its output. If this is 
a file, you should precreate 
it as an expandable sequential 
file. 



ANALYZE RUNNING SYSTEM?: Enter YES to analyze the 

currently running system. 
Enter NO to analyze the crash 
dump. The default is NO. 



DISK DEVICE NAME: 



CRASH FILE NAME: 



Enter the name of the disk 
unit on which the crash file 
is written. The default is 
DS01. The crash file must be 
at the volume catalog level. 

Enter the name of the file 
containing the crash dump. 
The default is S$CRASH. 



If ANALZ is running in batch mode, that is, you specified a file 
or sequential input device as the control access name, each input 
value or command must start in column one of a separate record 
(or card) . Batch input to ANALZ allows you to keep a standard 
ANALZ command stream on file or cards which can be easily and 
quickly executed after every system crash. 
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A. 3 COMMANDS 

When you enter the XANAL command, you invoke the ANALZ utility. 
Use the auxiliary commands under XANAL to select certain areas of 
the memory dump on the crash file (or actual memory, if it is 
analyzing the running system,) format them, and write them to the 
listing device. Auxiliary commands write 9 columns of four-digit 
numbers. The left hand column contains the address of the first 
word on each line, and the remainder of the line contains 8 
columns of 4-digit hexadecimal numbers. The auxiliary commands 
also write an abbreviated ASCII representation of the eight words 
to the right of the hexadecimal representation. Byte values that 
do not represent a character appear as periods ("."). For 
example : 

MEMORY DUMP FOR TSB/PDT/ SEGMENT 0000 , BETWEEN 00000382 AND 00000410 

0382-0356 2BA2 0001 0000 0E4D 51F4 9562 0002 . V + M Q 

0392-0077 0012 924A 0288 9562 3BB2 419E 0001 J .. .. 5. A. .. 

03A2-0000 250F 0000 0000 0000 0000 0000 0000 . . '/.. . . 

03E2*0000 0000 0000 0000 0000 0000 0000 454F . . EO 

03F2-5300 3C56 0460 B98A 908F 0024 F000 045A S. <V * . . . Z 



Table A-l shows the auxiliary commands and the action each 
performs. 
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Table A-l Auxiliary XANAL Commands 
Command Function 

AL Perform the following auxiliary commands: GI , TS, SS, 
MM, AQ, PQ, TR, TA , and a DM with 0, 0, and >FFFF 
as parameters. Perform them in the listed order. 

AM Perform the same commands as AL, omitting TA. 

AQ List a representation of the four active queues. 

DI List disk information (simple map disk function) . 

DM Dump a specific area of memory. 

FC List the FCBs for all currently assigned files. 

GI List general information about the system crash. 

LD List the LDTs for all assigned LUNOs in the system. 

MM List a map of memory. 

PB List the PBMs for all installed disk volumes. 

PD List the PDTs for all devices in the system. 

PQ List a representation of the other system queues. 

PS List the PSBs for all procedures in the system. 

QU Terminate execution of the ANALZ command. 

SA List the System Table Area. 

SS Write memory images of the system structures. 
(Perform TB, PS, PD, FC, P3, and LD commands 
in that order.) 

TA List memory images of every task area in memory. 

TB Lists the TSBs for all tasks in the system. 

TR List the workspace register contents of all tasks 
in memory. 

TS List task state of all tasks in memory. 



A-4 939153-9701 



System Design Document System Crash Analysis 



Normally, you need to execute only the AL or AM command to obtain 
enough information about a crash. The following paragraphs 
describe the results of some of the commands in more detail. The 
commands appear in the order in which the AL command executes 
them, (see Table A-l) . Useful information is also provided for 
determining the reason for the crash. 

A. 3.1 General Information (GI) Command 

The GI command lists general information about the crash. 

A. 3. 1.1 Crash Code. The first entry is the system crash code, 
(also called screech code) that the front panel displayed when 
the crash occurred, as well as an English translation of the 
code. See the DX10 Operatin g System Error Reporting and Recovery 
Manual (Volume VI), for a description of the crash codes. 

A. 3. 1.2 Executing Task. The second entry is the address of the 
task status block (TSB) of the task that was executing when the 
crash occurred. When this value is zero, the crash occurred 
within the operating system, during a scheduling cycle or in a 
Device Service Routine (DSR) * 

A. 3. 1.3 Location of Failure. The third entry is the address at 
which the crash routine was called. In some cases, this entry 
points to the exact location of the crash. However, in most 
cases, this value is the location of a common crash point that is 
entered from any of several locations. 
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A. 3. 1.4 Status Register. The fourth entry lists the value of 
the status register when the crash routine was called. The 
status register information is valuable when the crash code is 
>20. The last four bits (last digit in the entry) of the status 
register is the interrupt mask. When the interrupt mask value is 
in the range >2 - >E, the crash was caused by an illegal 
interrupt. When the interrupt mask value is 1, the crash was 
caused by one of the task error states occurring within the 
system or system task. 

A. 3. 1.5 System Variables. A set of system variables is printed 
after the status register value. Most of these do not contain 
useful information. Three of the variables may be of some 
impor tance . They are : 



MEMSIZ Total amount of memory in the system 

expressed in beets (32 -byte blocks) . 
This is useful in determining the 
amount of memory space available for 
system and user tasks. 

NUMDEC Negation of the number of time units 

since the last scheduling action. 
If. this number is unusually large, 
a task may be in a loop with the 
scheduler suspended or the scheduler 
itself may be in error. 

RSTRSW Flag that tells if the system has 

completed initialization. If the 
flag is set to -1 (>FFPP) , the crash 
occurred because the system was not 
initialized. 



A. 3. 1.6 Fixed and Runtime Task IDs. These entries are bit maps 
of all fixed and runtime task IDs. They are generally of no 
value in a crash analysis. 

A. 3. 1.7 System Patch Area. A dump of all out-of-line patches 
that have been applied to the system by the MEMRES patch file is 
listed. This is used to verify that all out-of-line patches have 
been applied to the system successfully. The beginning address 
of the patch area should be equal to the value assigned to S$PAT. 
The last five lines of the patch area will give the revision 
letter of the release. The revision letter should be checked to 
make sure that all recent patches have been applied. 
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A. 3. 1.8 Monitor Registers and Stack. The monitor registers are 
the registers of the executing task at the time of the crash. RO 
of* these registers will often contain the code of an error that 
caused the task to abort the system. The error codes are as 
follows: 



Code 



Explanation 



Notes 



1 
2 
3 
4 
5 
6 
7 
8 



9 
A 
B 
C 
D 
E 
F 



Memory parity error 

Illegal instruction 

TILINE time-out 

Illegal SVC code 

Mapping violation 

Privileged instruction violation 

Terminated by a Kill Task SVC 

Installed memory configuration is 

not big enough to allow task to 

be loaded 

Map segment not in memory 

Execute Protect Violation 

Write Protect Violation 

Stack Overflow 

Hardware Breakpoint 

12 Millisecond Clock 

Arithmetic Overflow 



(990/12) 
(990/12) 
(990/12) 
(990/12) 
(990/12) 
(990/12) 



R10 is the stack pointer for the task. A segment of the stack 
will be printed following the workspace registers. The stack 
pointer can be used to trace back through the stack to determine 
if a lower tier routine has passed an error code. 



A. 3. 1.9 Interrupt and XOP Vectors. The hardware interrupt and 
XOP trap vectors should be examined to verify that they are 
intact. Since these values reside in the first locations of 
physical memory, they are often destroyed by a system or 
privileged task that branches to memory location zero. Usually, 
the locations that are destroyed are locations 0-3 (power-up 

locations 1A-1F (interrupts six and seven) . 
often loaded with a bad value when a data word 
task is not specified. Locations 1A-1F are 
a task executes a BLWP instruction to location 0. 
When the BLWP instruction occurs, the return context of the task 
will be in locations 1A-1F. When a >20 crash occurs, and the 
interrupt mask indicates a defined interrupt (mask value minus 
one) , the interrupt trap values should be checked to determine if 
they are within the proper address range. Except for interrupt 
levels 0, 1, 2, and 5, the workspace pointer and program counter 
for each trap should point to about the same locations. 



interrupt) or 
Location is 
required by a 
destroyed when 
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A. 3. 1.10 Internal Workspaces. The last data printed are "tne 
workspaces for the clock processor, the interrupt 2 processor, 
and the SVC processor. These routines are entered through 
context switches, so the return context will be found in 
registers R13-R15 of these workspaces. The clock workspace will 
contain the location in the executing task where the last clock 
interrupt occurred. The SVC workspace will contain the location 
of the last supervisor call. These two locations can sometimes 
help determine where a task was at the time of the crash. The 
interrupt 2 workspace contains diagnostic information about a >20 
crash. R13-R15 contains the context of the crash within the 
system. Rl contains the error code (listed on the previous page) . 
When looking at the saved status register for interrupt 2 (R15) , 
check to see if bit 8 is set or reset. If bit 8 is set, the crash 
occurred in task driven code. If bit 8 is reset, the crash 
occurred in system code. It may be necessary to dump memory 
around the location pointed to by R14 and check the listing to 
determine if the code has been modified. 

A. 3. 2 Task State (TS) Command 

The TS command lists the most commonly referenced terms from the 
TSBs of the tasks in the system. The list contains, for each 
entry, the task ID, the task context at the last time the task 
was scheduled or performed a supervisor call, the current stgr'^ 
of the task, the task flags, and the TSB address. The ^ ; 
status block list follows the listing of commonly referenced 
terms. The task flags contain useful information in bit 5: when 
this bit is set, the task has been rolled out to disk; when this 
bit is reset, the task is in memory. By examining this bit for 
each task, the user can determine which tasks were in memory and 
may be associated with the crash. 
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A. 3. 3 System Structures (SS) Command 

The SS command lists the TSB, PSB, PDT, FCB, and LDT information 
from the system. The system templates and/or data structure 
descriptions are helpful when examining the SS command listing. 

A. 3. 3.1 Task Status Block (TSB). The TSB listing gives the 
entire TSB for every task in the system. The TSB contains all 
the information about the task that is used by the system. The 
most important fields in the TSB listing are the end action 
address, the second flag word, the task diagnostic field, and the 
task map file. 

The end action address entry contains the starting address of the 
memory task segment. This parameter is helpful when partial 
links of the system segments are available (provided with DX10 
source) . By taking the end action address entry, and locating 
where the task segment is in one of the partial links, the 
location of other system parts can be found. The length of the 
root segment can be found from the partial links. The starting 
address of DMGR, which is the start of the memory resident task 
segment, can be located in the TSB listing. By subtracting the 
length of the root segment from the starting address of DMGR, the 
starting address of the root can be determined. The starting 
address of the root segment is useful in determining if the crash 
was caused by DX10. 

The second flag word in the TSBs contains information about the 
task. If the task is being debugged, the first seven bits of the 
flag word contain information regarding the debugger; otherwise 
the first seven bits are set to zero. If the task is suspected 
as causing the crash, the flags should by verified with the 
templates, and TMRWT and the DEBUGGER modules should be examined 
for possible problems. 

The diagnostic information field in the TSB contains the 
interrupt 2 values for a task that has taken end action. This 
field is helpful when analyzing a crash code of >27. The >27 
crash is caused by TMEXT being non-zero when a task is killed. 
Often this occurs when a system task sets TM$EXT to suspend 
scheduling, then takes end action. Thus, even though a task may 
have a unique crash code, a >27 crash may occur because of these 
circumstances. The diagnostic information contains the context 
vector of the task at the time it was aborted. By taking these 
values, the listings can be examined to determine what conditions 
caused the abort (if the source listings are available) . If the 
listings are not available, this information is useful in 
discovering a faulty module, if subsequent crashes occur within 
the same task area. 
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The task map file is also kept in the TSB. The map file consis 
of three segments, with each segment containing a limit and a 
base. When a memory management problem is being considered, or 
an unexplainable map violation occurred from the task, the task 
map file should be examined. To find the upper limit of a task, 
find the last limit register that is not equal to >FFFF and 
negate it. The task should be able to address memory locations 
up to that point. To check for a memory management problem or a 
TILINE time out problem, the location of each segment in physical 
memory should be determined. This is done by the following 
formulas: 



Segment 

1 
2 
3 



Beet Address 

Bl 
B2+(-Ll/32) 
B3+(-L2/32) 



Beet Length 

-Ll/32 
(Ll-L2)/32 
(L3-L2)/32 



Note: 

T~. The map file = Ll, Bl, L2, B2, L3, and B3. 



The segment beet address can be checked against MEMSIZ (GI 
command listing) to see if the beet address exceeds the memory 
limit. Also, the segment can be checked on the time ordered list 
(MM command listing) if a memory management error is suspected. 

A. 3. 3.2 Procedure Status Block (PSB) . The PSB list follows the 
TSB list. These entries contain the memory Beet address and the 
length of the segment in Beets. It may be necessary to verify 
the procedure locations in memory and check for their entry on 
the time ordered list (MM command listing) . The procedures have 
a count of tasks that are attached to them. If the procedure is 
flagged as memory resident, then this count must always be at 
least one. There is no link to the attached task(s) in the PSB; 
this link is maintained by the tasks in the TSB. 

A. 3. 3. 3 Physical Device Tables (PDT) and Device Buffers. The 
next items listed are the PDTs. The PDTs define every device i n 
the system. The device buffers are shown with the PDTs; these 
are meaningful only if the device is marked assigned and busy in 
the PDT flag field. The first two words in the PDT contain the 
PDT link and the map file address and are not included in the PDT 
workspace. If a crash occurred when the system was in a DSR, the 
general location of the PC can sometimes be found by looking at 
the PDT workspace registers 5 and 6. These registers often 
contain either the interrupt entry vector or a BLWP vector used 
in the DSR. R5 contains the workspace pointer, and R6 contains 
the program counter. 
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All keyboard devices have a keyboard status block (KSB) as the 
last part of the PDT. The KSB contains a ring buffer for the 
characters being input. By looking at this buffer, the last 6 
characters input can be determined. Also, the KSB flags contain 
information about an SCI bid and whether SCI is active at the 
terminal. 

The TILINE and diskette drive PDTs have an extension for each 
controller. The controller can have up to 4 drives associated 
with it. There is one PDT per drive. The extension is found on 
the first drive PDT. The extension indicates the number of 
drives that the controller services. The PDTs for TILINE devices 
also contain the last TILINE image that was sent to or from the 
device. These parameters are useful in isolating disk problems 
when the crash was related to the disk or the crash was forced by 
the user, when disk activity was 100% and the system was in a 
"hung" state. 

A. 3. 3.4 File Control Blocks (FCB) . The FCB list gives all the 
files that were assigned at the time of the crash. Each disk 
drive has a list consisting of its VCATALOG entry and all the 
directories and files under it. Each FCB contains information: 
the file name, pointers to its parent directory, disk allocation 
space, and logical and physical record sizes. This list is most 
useful on a running system when a drive cannot be released 
because of LUNO assignment. When the FCB LUNO count is zero, the 
FCB should be released. If an FCB is in memory with a LUNO count 
of zero (see system templates) , the file is released by assigning 
a LUNO to that file, and then releasing it. This allows FUTIL 
another chance at removing the FCB. A disk will not be released 
until the only file opened under it is VCATALOG. The FCBs are 
also helpful with FUTIL and file management crashes. The FCB 
list shows all the files in the system at the time of the crash. 
The FCBs can then be examined to determine which file or files 
were involved in the crash. 

A. 3. 3. 5 Disk Partial Bit Maps. Each disk that is installed has 
information concerning its ADU allocation printed in the dump.^ A 
3-entry list is given for each sector of track that contains 
disk allocation information. The list entries contain the size 
of the biggest ADU block for each sector, the size of the first 
block, and the size of the last block in that sector. There is 
room in each sector of the bit map to define 2032 ADUs. The disk 
bit map is printed next. Each entry has one word of overhead and 
127 words of bit maps. The allocation information is of little 
use when analyzing a crash; it tells only if the disk is full. 
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A. 3. 3. 6 Logical Device Tables (LDT) . The last listing printed 
by the SS command is the LDT list. The LDTs provide information 
about LUNO assignment in the system. Every task, station, and 
global LUNO is listed, with global LUNOs listed first, then 
station and task LUNOs listed in order of TSB. The LDT contains 
the LUNO number and the pointer to the associated file or device. 
When the LUNO is assigned, the TSB field will contain a non-zero 
value pointing to the TSB that owns the LUNO (see system 
templates). The LDTs are structured as a forward- linked list. 
The task LUNOs will point to the global LUNO list, either 
directly or through a list of task LUNOs. The LDT information is 
most helpful when using ANALZ on a running system. The LDT 
information can show why a LUNO is not being released and what it 
is pointing to. When examining the listing for a particular 
LUNO, the first LDT with the LUNO desired is looked at first. 
There may be more than one LDT with the same LUNO. The 
information in the first LDT is checked, and if this does not 
solve the problem, the next is examined. The LDT list can also 
be used in diagnosing file utility (FUTIL) problems in a crashed 
system. 

A. 3. 4 List Memory Map (MM) Command 

The MM command lists information about the system mapping scheme, 
memory within the system table area, memory in the user tasfj 
area, and system overlay segment usage. This set of entrieU 
should be examined whenever memory management might be involved 
with a crash.* 



A. 3. 4.1 System Memory Maps. The system memory maps listing 
contains the current pointer to the map map file, followed by 
all the system map files defined in the system. Each entry in 
the map file list contains seven words. The first word given is 
the overlay ID of the system image. This should correspond to 
one of the overlay IDs on the link map of the system. (The IDs 
listed in the dump are in hexadecimal, while the IDs in the link 
map are in decimal. This is used only if the link maps of the 
system are available) . The remaining six words are the map file 
registers. These are the same as explained for the TSB listing. 
The first several entries are always the same, as follows: 

1 File Management and Key Indexed Files 

2 Memory Resident Tasks 

3 User Common Area 

4 I/O Common Area 

5 Scheduler 

6 Disk Device Service Routine (DSR) 
7+ DSR for Each Remaining Device 

The current map file (CURMAP) pointer is usually pointing to tlM 
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scheduler map file, entry five in the map file list. When a 
crash occurs and CURMAP is not pointing to the schedular map 
file, the problem is within one of the DSRs. Whenever a crash 
occurs and the interrupt mask (bits 12-15 of the status register) 
does not equal >F, CURMAP and the map file it points to should be 
checked. The addresses of the device DSR maps are found in the 
second word of the device PDT. When the PDT is dumped, the map 
file can be verified by checking that the second word of the PDT 
points to one of the listed map files. The memory for the DSR is 
examined by supplying the PDT address (not the TSB address) for 
the Dump Memory (DM) command. 

A. 3. 4. 2 System Table Area. The system table area contains 
system usage information and a list of available memory. Crashes 
that are caused by too little table area can be determined by 
looking at the system table header. A >30 crash occurs when the 
system table overflows. The overflow can be determined by adding 
the starting address of the table (located in the header) and the 
total length of the table (also located in the header) . If this 
sum is greater than the highest address allocated, a system table 
overflow has occurred. When the system crashes because of a 
table overflow, DX10 should be generated with a larger table 
area. 

The remainder of the table area defines the free space chain of 
available memory. The header information gives the address of 
the first byte available. The remaining entries give the length 
of that block in bytes and an address pointer to the next 
available block. The list is ended with a zero pointer. 

The system table area contains many structures of 10-100 bytes. 
When the system table area is heavily fragmented and approaching 
100% utilization, some devices (such as diskettes) may not be 
able to obtain memory for the device buffer, and cause a table 
overflow crash. When this occurs, the size of the system should 
be evaluated and resizing the system by system generation should 
be considered. 

Tasks with a coding error can cause a table overflow crash by 
using an unusual amount of table area. When this occurs, the 
table area listing contains many structures of the same type and 
size. Each entry in the system table lists its size in bytes. 
An example of this type of crash occurs when a COBOL program 
performs record locking on every record of a very large (20,000) 
record file. The system table area will have many RTL entries 
and will overflow. Programs that cause this type of crash should 
be rewritten . 
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A. 3. 4. 3 User Memory Area. The user memory area consists o 
three parts: the user memory header, the available memory list, 
and the time ordered list. All values in these tables are given 
in beets (32-byte blocks) . The user memory is considered to be 
all of the physical memory that is not taken up by the memory 
resident segments of the operating system. 

The user area header contains a pointer to the first available 
block of memory, the starting address of user memory, and the 
total length of user memory. No user task can be greater than 
the total length of memory. A crash normally does not occur from 
this unless the available memory space is less than 32K words or 
>800 beets. Also, no address on any of the three lists should be 
greater than the total length of memory (MEMSIZ) . If this 
occurs, it indicates an error in memory management. 

The available space list is a list of the blocks of memory 
available for user programs and their beet lengths. This is a 
linked list, with each entry containing a length word and a 
pointer to the next available block. These entries are kept in 
the first two words of the first beet of the block. 

All user tasks, procedures, and blocking buffers that are not 
defined as memory resident are found on the time ordered list 
(TOL) . Each of these segments have one beet of overhead that 
links them on the time ordered list. The TOL beet contains the. 
block length, the associated structure address, the forward link» 
the backward link, and the segment type. Blocks on the TOL are* 
located by looking at the pointers in the preceeding or 
succeeding block, which contain the beet address of the desired 
block. The beet address of each block is not found at the front 
of the entry. 

The TOL is a circular list that is headed by a beet found at the 
start of memory. The segment types are as follows: 

>FFFF Header Entry 

Blocking Buffer 

1 Task Segment 

2 Procedure Segment 

3 Available Block 

The header entry appears first on the list and should not be 
repeated. No buffer on the TOL should have a segment type of 
three. 

The user area list is useful for diagnosing a crash that was 
forced, due to roll in/roll out deadlocks. Deadlocks can be 
caused by an area of memory being "lost" to the system? that is, 
the pointer to a memory block may have been accidentally deleted. 

Memory can be verified by checking all memory on the TOL and the 
available space list. Memory is verified by finding the first 
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segment of the user area, then adding its length to its starting 
address to find the second segment. That segment should be 
located on either the TOL or the available space list. ^ach 
segment of memory is then checked in similar fashion, until all 
of the segments are accounted for or the missing segment is 
found. If a segment is missing, this indicates a problem in 
memory management which should be handled by a Texas Instruments 
representative. When checking the available memory list, care 
must be exersized when the task loader was active at the time of 
the crash. The loader may have been in the process of delinking 
a block of memory. 

Anytime an entry or pointer in the lists is greater than MEMSIZ, 
the entry is in error. This is usually caused by memory 
management allocating a second block of memory over the top of 
the first block allocated. The segment that overwrote the first 
should be examined for conditions that would cause memory 
management to put that segment at that location in memory. 

NOTE 

Do not try to look at the TOL on an active 
system. The memory chain will change while 
ANALZ is scanning the list, causing ANALZ to 
print meaningless data. 



A. 3. 4. 4 System Overlay Areas. The system overlay area 
information gives the address of each overlay area, the status of 
the area, and the overlay ID. This listing is useful only if the 
crash occurred when the system was executing in one of the 
overlays. When the crash occurs in an overlay, this area is used 
to find the overlay. The system listings indicate the correct 
code that should be in the overlay area. 

A. 3. 5 List Queues (AQ and PQ) Command 

The AQ command is used to list the four active queues of the 
system. The PQ command is used to list other queues in the 
system. The active queues show the tasks queued for execution at 
the four priority levels of the system. The other queues include 
the file utility queue (FUTIL) , the waiting on memory queue, the 
system log queue, and the device queues. These queues may be of 
importance during a system crash. 
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The queues listed by the PQ commands should not have more thaj 
three entries, except for the waiting on memory queue, where thlj 
length of the queue is a factor of system load versus system 
memory. When a queue is found to be unusually long, the queue 
processor should be checked to see if it is still active and the 
state it is in. 



A. 3. 5.1 FUTIL Queue. The file utility routine (FUTIL) services 
all create file functions and all assign LUNO functions to files 
and devices. The FUTIL queue is sometimes large because of the 
type of operation it is performing, such as creating large key 
index files. The queue processor should be checked when this 
occurs. Sometimes the FUTIL queue and processor will be blocked 
when performing I/O to a device. Some devices, such as line 
printers, have a long time-out associated with them. When the 
device is offline, and FUTIL is trying to assign a LUNO to the 
device, FUTIL is suspended until the time-out is performed. 
During that time, no other entry on the FUTIL queue can be 
serviced. Users may force a crash when this occurs, because it 
appears that the system is in a roll in/roll out deadlock. Some 
crashes are caused by a FUTIL roll in/roll out deadlock. 
Sometimes FUTIL will be rolled out of memory with a longer than 
average queue, and will not be able to obtain memory for roll in. 
When this occurs, it must be determined why FUTIL cannot get 
memory and what routine is supposed to handle that condition. 
The listings of the task loader area should contain the routine 
that handles FUTIL memory management. 

A. 3. 5. 2 Waiting on Memory Queue. The waiting on memory queue 
contains the task status blocks (TSBs) of all tasks that are 
ready to execute but need memory. This queue grows in proportion 
to the number of tasks that are in the system and the size of 
available memory. There are times when no task is executing, and 
every task is on this queue. When this happens, the system 
deadlocks and crashes are usually forced. Conditions that lead 
to this are when tasks lock other tasks into memory without 
following the rules of the operating system. The most common 
occurrence of this is when a device tries to simulate TILINE I/O, 
which locks a task into memory, and the task does not set the 
supervisor control block (SCB) flag when the I/O completes. The 
SCB flag indicates to the system schedular that end-of-record 
processing must be performed, and that the task can be rolled out 
of memory. When this flag is not set, there is the possibility 
that the roll out algorithm will be caught in an endless loop. 
Other situations that lock tasks into memory and cause deadlocks 
are file management requests and alternate TSB servers. 
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Another situation that causes the waiting for memory queue to 
grow, and causes system deadlocks, is problems with the system 
disk. Sometimes the disk will go offline and roll in/roll out 
cannot be performed. The system log and system log queue should 
contain error messages when the system disk is in question. 

A. 3. 5. 3 System Log Queue. The system log queue contains all the 
system log messages that are waiting to be written to the system 
log device. System log messages will be kept on the queue if the 
system log device has not been initialized or if the queue is 
getting more messages than the system log device can handle. In 
this second case, the messages on the queue will often give a 
clue as to what went wrong with the system before the crash 
occurred (for example, when there are problems with the system 
disk) . 

A. 3. 5. 4 Device Queues. Each device has a queue list anchored in 
the PDT. This queue is a list of I/O requests made to that 
device. When a particular device is off-line or down, and the 
device has no time out value, the list may become long. When a 
crash is forced because a task would not come back from an I/O 
request, the device queues should be checked for the task 
requesting I/O and for unusual queue length. The system 
templates indicate where the queue pointer is in the PDT. 

A. 3. 6 Task Registers (TR) Command 

The TR command lists all of the workspace registers of the tasks 
that are in memory at the time of the crash. Workspace registers 
10 and 11 are useful in determining where the task was executing 
at the time of the crash. Registers 10 and 11 give the stack 
location for the task and where the last return from a branch and 
link (BL) was in the task. These registers are used with the 
task listing to locate where the task was executing, and the data 
structures it was executing on. Register 10 points to the area 
containing information on routines called and parameters passed 
to them. 



A. 3. 7 Task Area (TA) Command 

The TA command lists two parts of memory: the task memory area 
and the system data base. 
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A. 3. 7.1 Task Area. The task area listing shows the raw memory 
dumps of the task segments. The procedure segments are not 
shown; these must be listed with the dump memory (DM) command. 
The push/pop stack is usually kept in the task segment and will 
be listed by this command when it is. You often need to 
determine if the task memory space has been altered. By checking 
the task area with a listing of the task, you can determine if 
any task memory has been wiped out. If several words have been 
destroyed, you can possibly determine which processor wiped out 
the code and what type of operation was being performed. File 
management and TILINE data transfers often cause destroyed code. 
By checking the SVC call blocks, the buffer areas of the transfer 
can be determined. An incorrect address in the SCBs will cause 
code to be wiped out. Another cause of destroyed code is caused 
by the TILINE device service routine not getting the right 
physical address of the output buffer. Common places where this 
is discovered is in the first 100 words of the system, or at 
addresses greater than >C000. The device service routines may 
have bugs when this occurs. 

A. 3. 7. 2 System Memory. This listing is a dump of the system 
data base. This area is the first module of the operating 
system, with the largest part being the system table area. It is 
often necessary to examine data structures that are not listed in 



the above sections of the ANALZ dump, but are found in the .syste 
table area. Sometimes the table area is modified, similar to t ' 



1 



modifications of the task area listed above. This part of th 
dump is important, because it lists the system data base without 
being restrained to data structures. 

A. 3. 8 All (AL) Command 

The AL command allows the user to do all of the functions listed 
above, in the order given, with one command. This is the most 
useful way of performing a crash dump analysis. It allows for 
easy referencing between different parts of the system without 
having to enter separate commands for each part to be analyzed. 
Two other commands are available for the analysis; these are 
listed below. 

A. 3. 9 Dump Memory (DM) Command 

The DM command is used to list memory not shown by any of the 
above commands. The DM command can be used in three ways. The 
first is to give a task status block address and a relative 
address within the task. This gives a list of the task area not 
given by one of the above commands. The second method is is to 
give the address of one of the physical device tables for the 
device. This gives the memory available for the DSR. This 
second method also allows for the viewing the system root and I/g, 
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common area. The third method is to list absolute memory. This 
requires a TSB address of zero, and a 21 bit absolute address. 
This method should be used when examining the time ordered list 
memory (that is, the memory pointed to by entries on the time 
ordered list) . 

A. 3. 10 Disk Information (DI) Command 

The DI command provides information on each file and directory of 
the system disk. This command is rarely used in a crash 
analysis. The information given by the DI command, for each 
file, is a follows: 

* File Name: the name of the file. 

* LRL: the logical record length of the file. 

* PRL: the physical record length of the file. 

* Size: the number of ADUs in the file. 

* Address: the starting ADU address of the file. 

* Logical EDM: the logical end of file address. 

* Block EDM: the physical end of file address. 

A. 3. 11 System Table Analyzer (SA) Command 

This command displays a breakdown of the system table area, 
including memory usage by the system queues, lists, and 
unallocated memory holes 

A. 4 ANALYZING >20 AND >27 CRASHES 

The most common types of crashes are >20 and >27 crashes. The 
following paragraphs give suggestions on how to start analyzing 
these crashes and what conditions to look for . 

A. 4.1 >20 Crashes 

The >20 crash occurs while the system is executing a system task 
(memory resident or disk resident) . The system task either takes 
end action, or receives an internal interrupt. 

A. 4. 1.1 Status Register. When a >20 crash occurs, first check 
the status register. If the last 4 bits of the status register 
do not equal one, the crash is caused by an illegal internal 
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interrupt. This indicates that a device interrupted at 
interrupt level that is not defined, or that a device interrupte 
within an expansion chassis and the device position in that 
expansion chassis is not defined. The value of status register 
bits 12 through 15 plus one indicate the interrupt level that was 
taken. The hardware configuration and the system generation 
listing should be checked to determine if the interrupt level 
taken is a legal interrupt. If the interrupt is legal, then the 
interrupt workspace is checked for a bad chassis position 
interrupt. A pointer to that workspace is at the beginning of 
memory at location interrupt level times four. Workspace 
register 9 will have the position value times 8 that caused the 
the interrupt. Divide the contents of R9 by eight, and check the 
hardware configuration to verify the chassis position. 

A. 4. 1.2 Interrupt Two Workspace. In most cases, the status will 
be >C001. This indicates a task error within the operating 
system. In the error interrupt workspace, register 1 will 
contain the task error code that caused the crash. These error 
codes are listed above under the description of the level 2 
workspace. When the error code is found, the contents of 
registers 13, 14, and 15 show the location of the crash, and the 
status at the time of the crash. If bit 8 of workspace register 
15 is set to one, the crash occurred in a user task; if it is set 
to zero, the crash occurred in a system task. The contents of 
register 14 is the program counter at the time of the crashj 
This code around this location should indicate what caused t» 
crash. The workspace pointer is in register 13; the task 
workspace is used to check indexed addresses. The task listing 
should be consulted to determine what instructions were being 
executed at the time of the crash. 



A. 4. 2 >27 Crashes 

The definition of a >27 crash is "TM$EXT non-zero during kill 
task", which is caused by a task taking end action while it has 
suspended the scheduler. The crash occurs before the end action 
is taken. When this crash occurs, the value of ETSK shows the 
executing task at the time of the crash. The TSB for this task 
(found in the TSB list) has a diagnostic information field 
containing the error code and the context of the task at the time 
of the area. With this information, the >27 crash is handled the 
same as the >20 crash. 
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Appendix B 
Regenerating DX10, SCI, SDSMAC, and XLE From Source 



B.l GENERAL INFORMATION 

A DX10 Release 3.2 (or later) system with FORTRAN installed must 
be used when it is desirable to regenerate DX10. Because of the 
large volume of data required, the regeneration process normally 
requires a 4-disk system to complete the process. The disks 
required are: 



System disk 

Source disk 
Listings disk 
Build disk 

Batch listings disk 



Contains a DX10 system, 5000 
contiguous sections of temporary 
space, and the FORTRAN compiler 
and run-time package. 

Contains source and object files. 

Contains the source listings. 

Disk onto which to build the 
new system. 

Contains the batch execution 
listings. Not necessarily 
a different disk. 



The system disk must be a DS10 or larger disk. The source disk 
must be a DS25 or larger disk (64176 sectors required) . 

The listings disk must be larger than a DS25 to contain all the 
source listings (102543 sectors required). The assemblies may be 
done so that the listing disk capacity requirement may be reduced 
by changing the disk during the course of the assemblies. It is 
recommended that a DS25 disk be the minimum capacity disk used. 
The additional files for the microfiche require an additional 
6624 sectors for a total of 109167 sectors. 

The batch execution listings disk may be a DS31 or larger disk. 
The batch listings require 5082 sectors. These listings may go 
to the system disk, the listngs disk, or any other disk in the 
system (excluding the source disk) . 

A single magnetic tape drive is required if the magnetic tape 
disk build media is to be done. 
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To execute the batch stream named VOLS RC. BATCH. LIN KBLD, the us# 
must have a privilege code of 6 or 7. ^ 



B.2 ASSEMBLING AND COMPILING DX10 

The DX10 source is logically divided into directories according 
to operating system function. These directories are described in 
this system design document. A batch stream is supplied for each 
operating system directory that will perform the conversion of 
source to object. These batch streams recompile or reassemble 
all source modules if the proper synonyms are correctly assigned. 
The required synonyms are: 

Synonym Value 

VOLSRC SYSBLD (volume name of source disk) 

VOLOBJ SYSBLD (volume name of object disk) 

VOLLST LIST3X (volume name of listing disk) 

VOLSYS ?????? (volume name of executing system disk) 

VOL$$BAT LIST3X (volume name of batch listings disk) 

The source disk supplied by Texas Instruments is named SYSBLD. 
Normally, the listing disk contains the release level in the 
volume name when the procedure is executed by Texas Instruments 
personnel. The names have been LIST30 for Release 3.0 and LIST31 
for Release 3.1. The name may be changed without impacting ttw* 
procedure. 

The following is a list of the batch streams to 
reassemble/compile DX10 : 

SYSBLD . BATCH . ASM . ANALYZ 
SYSBLD . BATCH . ASM . DEBUGR 
SYSBLD. BATCH. ASM. DEVDSR 
S YSB LD . BATCH . ASM . DSCBLD 
SYSBLD . BATCH . ASM . DSCMGR 
SYSBLD . BATCH . ASM . DX10 
SYSBLD . BATCH . ASM . DXMISC 
SYSBLD . BATCH . ASM . DXDTIL 
SYSBLD. BATCH. ASM. FILMGR 
SYSBLD. BATCH. ASM. PUTIL 
SYSBLD. BATCH. ASM. GEN 990 
S YSBLD. BATCH. ASM. K I PILE 
SYSBLD . BATCH . ASM . MEMMGR 
SYSBLD . BATCH . ASM . NOSHI P 
SYSBLD . BATCH . ASM . PGFI LE 
S YSBLD. BATCH. ASM. SYSTSK 
SYSBLD . BATCH . ASM . TSKMGR 
SYSBLD . BATCH . ASM . UTCOMM 
SYSBLD. BATCH. ASM. UTDIRP 
SYSBLD. BATCH. ASM. UTDXTX 
S YSBLD . BATCH . ASM . UTGENR 
SYSBLD . BATCH . ASM . UTSVC 
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Assign the synonyms and execute each of the batch streams with 
the XB command. The approximate run time is 13 hours. 



B.3 ASSEMBLING SCI 990 

To assemble SCI990, execute the following batch stream with the 
same synonyms assigned as required for DX10 reassemblies: 

SYSBLD. SCI 990. BATCH. ASM 
This batch stream runs approximately 3.25 hours. 

B.4 ASSEMBLING SDSMAC 

To assemble SDSMAC, execute the following batch stream with the 
same synonyms assigned as required for DX10 reassemblies: 

SYSBLD . SDSMAC . BATCH . ASM 
This batch stream runs approximately 2.5 hours. 

B.5 TRANSLITERATING THE LINK EDITOR 

To transliterate the link editor, execute the batch stream named: 
SYSBLD. LINKER. UTILITY. INSTALL. 

This installs the transliterator required to translate and 
assemble the link editor source. Use the same synonyms assigned 
for DX10 reassemblies. When this batch stream has completed, 
execute the batch stream named: 

SYSBLD. LINKER. BATCH. ASM 
This batch stream runs approximately 2.2 hours. 
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B.6 LINK EDITING DX10 

Assign the following synonyms and then execute the following 
batch streams: 



Syno nym 



VOLSRC 


SYSBLD 


VOLOBJ 


SYSBLD 


VOLBLD 


REL32 


VOLSYS 


?????? 


VOL$$BAT 


LIST3X 


Batch Stream 



Value 

(volume name of source disk) 

(volume name of object disk) 

(volume name of disk to build) 

(volume name of executing disk) 

(volume name of batch listings disk) 



SYSBLD. BATCH. DXLINKS 

SYSBLD. BATCH. UTLINKS 

SYSBLD . BATCH .GENP ARTS 

SYSBLD. SCI 990. BATCH. LINK 

SYSBLD. SDSMAC . BATCH . LINK 
SYSBLD . LIN KER. BATCH . LINK 



Function 

Pre-links and links of 

DX10 parts 
Pre-links and links of 

all utilities 
Compress object for SYSGEN 

parts 
Link Of command interpreter 

parts 
Link of macro assembler 
Link of link editor 



The approximate run time is 2.9 hours. 



B.7 BUILDING THE DX10 SYSTEM DISK 

Install a new disk in drive DS03 (must be DS03 for MVI commands) . 
Initialize the volume using the INV command and the following 
responses: 

[] INV 



initialize new volume 
unit name: 
volume name: 
nqmber of vcatalog entries: 

BAD TRACK ACCESS NAME: 



DS03 

REL33 

100 (DS32), 200 (DS10), 

342 (DS25, DS50) 

DUMY 
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NOTE 

If drive DS03 is not available for this 
purpose, it may be changed but with 
difficulty. One must text edit a file on the 
master source disk to change the operand for 
the disk drive for the MVI command. The file 
pathname is 3YSBLD.MVICONT. The first line 
of the file contains the entry DS03 that must 
be changed to the name of the available 
drive. This change and changing the operand 
for the drive response of the INV command 
above are the only changes required. Proceed 
with caution since the master disk must be 
written to when QUITING the edit session. 



Assign the synonyms as described for the links and execute the 
following batch streams: 



Batch Stream 



Function 



SYSBLD.BATCH.BLDX10 
SYSBLD. SCI990. BATCH. SCI990 
SYSBLD.BATCH.PROCO 
SYSBLD . BATCH . PROC 2 
SYSBLD. BATCH. PR0C4 
SYSBLD . BATCH . PROC 6 
SYSBLD . BATCH . MENU 
SYSBLD .BATCH . SDSMAC 
SYSBLD. LINKER. BATCH. INSTALL 
SYSBLD . BATCH . PROTCT 



Build the new DX10 system disk 
Install the command interpreter 
Install SCI procedures (level 0) 
Install SCI procedures (level 2) 
Install SCI procedures (level 4) 
Install SCI procedures (level 6) 
Install the SCI procedure menus 
Install the macro assembler 
Install the link editor 
Delete protect the system tasks 



The approximate time is 1.1 hours. 
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Patch the system just built by copying and editing the file nameti 
REL33.PATCH.MEMRES. The instructions for editing the file are 
contained in the first few lines of the file itself. Use the 
Copy /Cone a ten ate utility to copy the file: 

ncc 



COPY/CONCATENATE 

INPUT ACCESS NAME(S): 

OUTPUT ACCESS NAME: 

REPLACE?: 

MAXIMUM RECORD LENGTH: 



REL 3 3 , P ATCH . MEMRES 
REL33 .PATCH. XMEMRES 
NO 
80 



Edit the file named REL 33 .PATCH. XMEMRES to assign the required 
synonyms. The link map for the built system is in the file named 
VOLOB J. DXLINK. MAP. S$ IMAGES. Assign the synonym $$DSC$ to the 
value REL 33 and execute the batch stream named 
REL 3 3. PATCH. XMEMRES. The runtime is approximately 5 minutes. 



Execute the batch stream named REL 33 .PATCH. PROGA 
system program file. This takes about 5 minutes. 



to patch the 



B.8 BUILDING THE DX10 DISK BUILD MAGNETIC TAPES 

To make the magnetic tapes for the magnetic tape disk build 
procedure, follow the instructions listed below. The synonyms 
assigned are to be used during the entire process. Three 
magnetic tapes are made requiring the following resources; 



System Disk 
Source Disk 



Contains system and temporary space. 

Contains source, object, and batch 
streams (SYSBLD) . 



Built DX10 System Contains a DX10 system as the result of 

the preceding procedure for building the 
DX10 system disk. 
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Assign the following synonyms: 

Synonym Value 



DSC SYSBLD 

DSC2 REL33 (new DX10 system disk) 



For Tape 1: Mount a 1200-foot magnetic tape in drive 

one (MT01) with a write-enable ring installed. Then, 

execute the batch stream named SYSBLD. BATCH. B ST 1. The 
approximate run-time is 25 minutes. 

For Tape 2: Mount a second 120 0- foot magnetic tape in 
drive one (MT01) with a write-enable ring installed and 
execute the batch stream named SYSBLD.BATCH.BST2. The 
approximate run-time is one minute. 

For Tape 3: Mount a third 1200-foot magnetic tape in 
drive one (MT01) with a write-enable ring installed and 
execute the batch stream named SYSBLD. BATCH. BST 3. The 
approximate run-time is 10 minutes. 
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Appendix C 
Scheduler Structure and Operation 

C.l PLOW OF CONTROL FOR DX10 SCHEDULER 

The following list is a detailed flow of control for the DX10 
task scheduler. The scheduler is entered when one of the 
following five conditions is met: 

* When the executing task suspends. 

* When a time delay task is due to become active. 

* When a task time slices out (if time slicing is 
enabled) . 

* When a device service routine (DSR) bids a task. 

* When the task sentry decides to lower the priority of 
the executing task. 

The scheduler is entered from the routine named TRAPRT, which is 
the common exit point for X0PRT2, X0PRT3, TM$DEC f and TM$CLR. 
The scheduler will not be entered if the scheduler inhibit flag 
(TM$EXT) is high, if the time slice extended flag (TMESLC) is 
non-zero, or if the previously executing task was in map file 0. 

The variable ETSK is a word in the root of DX10 that points to 
the TSB of the currently executing task. When no task is 
executing, ETSK is null. 

?^ f i°?, of contro1 for the task scheduler is given in the steps 
that follow: ^ 

0.0 MAIN ENTRY POINT (defined as SLCSUS) 

1.0 ETSK NULL? 

If ETSK points to a TSB when the scheduler is 
entered, then either this task was time sliced 
out, a device service routine (DSR) bid a task, a 
time delay task was due to become active, or the 
task sentry decided to lower this task's priority. 

YES - GO TO 3.0 
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2.0 



Put the TSB pointed to by ETSK on the active queue, 
task sentry for CPU-bound tasks, and 
set ETSK to zero. 



3.0 CLEAR: 



These flags are cleared each scheduling cycle: 
Time slice ended flag (TM$DFR) j 
Scheduler inhibit flag (TM$EXT) ; 
Time slice extended flag (TMESLC) . 



4.0 UPDATE TIME AND DATE 

The number of elapsed system time units 
to the computer clock calendar. 



is added 



5.0 UPDATE TIME DELAY TASKS 

Time delay tasks also are updated by the number of 
elapsed system units. If the task is due to 
become active, the scheduler puts it in an active 
status. 



6.0 HAS A SYSTEM TIME UNIT ELAPSED? 

The timeout logic for device service routi 
should be entered at 50 millisecond interval' 
i.e., each system time unit. 

YES - GO TO 8.0 



m 



7.0 HAS A DSR BID UP A TASK? 

If a DSR bids a task, then the global variable 
BIDTSK is non-zero. If this is the case, the DSR 
timeout must be entered now. 

NO — GO TO 9.0 



8.0 CHECK REENTER-ME AND TIMEOUTS FOR PDTS (BLWP TMOUT) 



9.0 IS TILINE END OF RECORD OUTSTANDING? 

Since tasks that do TILINE I/O are locked into 

memory, do a TILINE end of record as soon as 

posible to allow the task to be rolled. If TILINE 

EOR is outstanding, the global variable SCB is 
no n- zero. 



YES — GO TO 24.5 



10.0 IS ACTIVE QUEUE EMPTY? 
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YES — GO TO 13.0 



11.0 GET HIGHEST PRIORITY TASK OFF ACTIVE QUEUE; 

SET ETSK TO PONT TO TSB OF HIGHEST PRIORITY TASK. 



12.0 IS ETSK A REAL TIME OR SYSTEM PRIORITY? 

If a real time or system task wants to execute, 
the scheduler does not attempt to service SCI bids 
during this scheduling cycle. 

YES — GO TO 19.0 



13.0 IS RESTART IN PROGRESS? 

No SCI bids are serviced until the system restart 
task has initialized the system. 

YES — GO TO 15.0 



14.0 SCAN KSBS FOR SCI BIDS 

The scheduler bids SCI for each KSB that requests 
it using the routine named TMBIDO. 

15.0 HAS A TASK BEEN SELECTED (Is ETGK not null)? 
YES — GO TO 19.0 

16.0 IS TASK LOAD IN PROGRESS (TMMLIP not null)? 

If the scheduler has previously requested a task 
to be rolled in, there is no need to try to roll 
in another task. 

YES — GO TO 18.0 

17.0 IS ANY TASK WAITING ON MEMORY (TMWOMO not null)? 
YES — GO TO 21.0 

18.0 GO IDLE (wait for interrupt). 
GO TO 3.0 

19.0 IS THERE AN ALTERNATE TSB FOR ETSK? 
YES — GO TO 22.0 
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20.0 SHOULD A TASK WAITING ON MEMORY BE LOADED? 

If a task waiting on memory is of higher priority 
or equal priority and ETSK has had a minimum 
number of time slices, if time slicing is 
available, then the task loader is given the CPU 
to load the waiting task. 

NO — GO TO 22.0 



21.0 REQUEUE ETSK ON ACTIVE QUEUE IF NOT NULL; 
SET ETSK TO POINT TO TASK LOADER TSB ; 
SET TMMLIP TO NONZERO (SIGNAL LOAD IN PROGRESS) . 

22.0 SET TIME SLICE COUNT 

Initialize the number of clock ticks for a time 
slice. If time slicing is disabled, a non-zero 
number is used here . 



23.0 IS END OF RECORD OUTSTANDING FOR ETSK? 

Since TILINE EOR was checked earlier, this is a 
check for CRU I/O. 

NO — GO TO 25.0 

24.0 REQUEUE ETSK ON THE ACTIVE QUEUE 

24.5 SET ETSK TO POINT TO DEVICE DRIVER TASK; 
GO TO 34.0 

25.0 IS THERE ANY ALTERNATE TSB PRESENT FOR ETSK? 
NO — GO TO 27.0 

26.0 SET ETSK TO POINT TO ALTERNATE TSB; 
GO TO 34.0 



27.0 IS THIS TASK QUIETING? 

Tasks that are quieting, have been selected to be 
rolled and are kept on the active queue until 
their I/O is finished. 

NO — GO TO 30.0 
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28.0 IS I/O IN PROGRESS? 
YES — GO TO 2.0 



29.0 PUT ETSK ON QUIET QUEUE; 

The task loader is a dedicated queue server of the 
quiet queue and will be activated when something 
is placed on its queue. 
CLEAR ETSK; 

GO TO 3.0 



30.0 IS LEAVE ALONG FLAG SET FOR ETSK? 
YES — GO TO 34.0 

31.0 IS ABORT FLAG SET? 
NO — GO TO 34.0 

32.0 IS I/O COMPLETE? 
NO — GO TO 2.0 

33.0 BRANCH TO END ACTION 



34.0 PROCESS GET CHARACTER SVC 

The processing necessary for the get character SVC 
is small and the SVC overhead is saved by moving 
the character from the TSB, placed there by the 
DSR, to task register 0. 



35.0 DOES AN OVERLAY NEED TO BE READ IN FOR ETSK? 
NO — GO TO 37.0 

36.0 PLACE ETSK ON OVERLAY LOADER QUEUE; 
GO TO 3.0 

37.0 IS ETSK UNDER CONTROL? 

This is a flag set in the TSB. 

NO — GO TO 39.0 
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38.0 PLACE ETSK IN STATE 6; 

Task suspended by the scheduler . 
CLEAR ETSK; 

GO TO 2.0 



39.0 SET UP TASK FOR EXECUTION 
Set task in state 7; 
Increment loader roll count (TSBTl) ; 
Put task memory on time ordered list (if not 
memory resident) 

40.0 GIVE CONTROL TO ETSK VIA A RTWP USING PC, WS , AND 
STATUS IN THE TSB POINTED TO BY ETSK. 



C.2 PREEMPTIVE EXECUTION 



Task scheduler operation is based on the concept of preemptive 
execution. Preemptive execution allows a higher priority task to 
have the CPU whenever it becomes active. For example, if task Tl 
with a priority of R5 is executing, and a task T2 of priority R2 
is bid, Tl is suspended and T2 is placed in execution. If Jrsk 
T3 of priority R0 is subsequently bid, T2 is suspended and "M . 
put into execution. Preemption is shown in Figure C-l. 



Time 



Task in 
Execution 



Active 
Task Queue 



Action 



ms. Tl 

30 ms. T2 pre-empts Tl T2 
50 ms. T2 



T1/R5 

T2/R2,Tl,R5 

T2/R2,T1,R5 



T2 is bid 



750 ms. T2 

783 ms. T3 pre-empts T2 T3 

800 ms. T3 

841 ms. T2 

850 ms. T2 



T2/R2,T1/R5 
T3/R1,T2/R2,T1/R5 
T3/R1,T2/R2,T1,R5 
T2/R2,T1/R5 

T2/R2,T1/R5 



T3 is bid 

T3 has 
completed 



Figure C-l Pre-emption 



Notes: 

Tl has an assigned priority of R5 

T2 has an assigned priority of R2 

T3 has an assigned priority of Rl 
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C.3 TIME SLICING 

Time slicing is a task scheduler option that can be selected at 
system generation (sysgen) time. Also specified at sysgen is the 
length of the time slice. This is defined as a multiple of 
system time units (at 50 milliseconds each) . The default 
parameters are to have time slicing, with each time slice is to 
be one system time unit (50 milliseconds) . When time slicing is 
invoked, the time slice value is the amount of CPU time that is 
given a task each. time it executes, and the next task to execute 
is the next task of the same priority. (This is somewhat 
different from the pre-DXIO 3.2/TX2.3/TX5 task scheduler as this 
scheduler only slices tasks of the same priority.) For example, 
take the case where time slicing is selected . and task *T4, 
priority R5, is the only task running. If task T5, priority R2, 
is bid, followed shortly by task T6, priority R2, then T5, and T6 
will alternate running for 50 millisecond time slices. When both 
have completed, task T4 is allowed to execute again. This is 
shown in Figure C-2. 
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Task in 



Active 



Time 



ms. 

50 ms. 

100 ms. 

128 ms. T5 pre-empts T4 T5 
150 ms. 
183 ms. 
200 ms. 
250 ms. 
300 ms. 
350 ms. 
400 ms. 



450 


ms. 


500 


ms. 


540 


ms. 


550 


ms. 


600 


ms. 


650 


ms. 


700 


ms. 


717 


ms. 


750 


ms. 


800 


ms. 


850 


ms. 


852 


ms. 


900 


ms. 


950 


ms. 


Notes: 


1. 


T4 : 


2. 


ts : 


3. 


T6 : 



Execution 


Task Queue 


Action 


T4 


T4/R5 




T4 


T4/R5 




T4 


T4/R5 




: T4 T5 


T5/R2,T4/R5 


Task T5 is bid 


T5 


T5/R2,T4/R5 




T5 


T5/R2,T6/R2,T4/R5 


Task T6 is bid 


T6 


T6/R2 , T5/R2 , T4/R5 




T5 


T5/R2,T6/R2,T4/R5 




T6 


T6/R2 , T5/R2 , T4/R5 




T5 


T5/R2 , T6/R2 , T4/R5 




T6 


T6/R2,T4/R5 


T5 suspends for 
I/O 


T6 


T6/R2,T4/R5 




T6 


T6/R2,T4/R5 




T6 


T6/R2 , T5/R2 , T4/R5 


T5 completes 
I/O 


T5 


T5/R2 f T6/R2,T4/R5 




T6 


T6/R2,T5/R2,T4/R5 




T5 


T5/R2 , T6/R2 , T4/R5 




T6 


T6/R2 , T5/R2 , T4/R5 




T5 


T5/R2,T4/R5 


T6 terminates 


T5 


T5/R2,T4/R5 




T5 


T5/R2,T4/R5 




T5 


T5/R2,T4/R5 




T4 


T4/R5 


T5 terminates 


T4 


T4/R5 




T4 


T4/R5 





T4 has an assigned priority of R5. 
T5 has an assigned priority of R2. 
T6 has an assigned priority of R2. 



Figure C-2 Time Slicing 
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C.4 TASK SENTRY 

Task sentry is the other scheduler option that can be selected at 
sysgen time. Also defined at sysgen is the task sentry value 
(expressed in multiples of system time units), if the task sentry 
is to be used. The sysgen default parameters are not to have 
task sentry selected, but if task sentry is selected, the default 
time value is 60 system time units (three seconds) . When task 
sentry is operational the operating system determines which task 
is running at the end of each system time unit. If the same task 
is running now as was running at the last check, an elapsed time 
counter is decremented. If a different task is running, then the 
elapsed time counter is reset to the task sentry value specified 
at sysgen. If the elapsed time counter reaches zero, the task in 
execution is lowered to the next lower priority value and placed 
at the bottom of the list for that priority level. The elapsed 
time counter is then reset, and the top task on the active queue 
is placed in execution. If task sentry places a task on a 
populated list, then the task is returned to its loaded priority 
level when it is next allowed to execute (i.e., task sentry 
cannot reduce a task priority below that of the next lower 
priority task in the system). Likewise, if a task terminates or 
suspends for any reason, its priority is reset to that the 
priority assigned to it when it was loaded. Figure C-3 describes 
this action. 
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Task in 


Time 


Execution 





ms. 


T7 


27 


ms. 


T8 


50 


ms. 


T8 


81 


ms. 


T9 


100 


ms. 


T9 


150 

• 


ms. 


T9 

• 


• 

3100 


ms. 


• 
* 

T8 


3150 


ms. 


T8 


3200 


ms. 


T8 



Active 
Task Queue 



Action 
Task T8 is bid 



T7/rT0~ 

T8/R9,T7/R10 

T8/R9,T7/R10 

T9/R8,T8/R9,T7,R10 Task T9 is bid 

T9/R8,T8/R9,T7,R10 

T9/R8 ,T8/R9 ,T7 , RlO 



T8/R9,T9/R9,T7/R10 Task T9 exceeds 

sentry 
T8/R9,T9/R9,T7/R10 Task T9 resumes 

execution 
T8/R9 ,T9/R9 ,T7/R10 



T9/R8,T7/R10 



6550 ms. 


T9 


T9/R9,T7/R10 


Task T9 exceeds 


• 


* 


• 


sentry 


• 
• 

9550 ms. 


• 

T7 


• 
• 

T7/R10,T9/R10 


Task T9 exceeds 
sentry 


9600 ms. 


T7- 


T7/R10,T9/R10 




9621 ms. 


T9 


T9/R8 


T7 suspends 
for I/O 


9650 ms. 


T9 


T9/R8 




9700 ms. 


T9 


T9/R8 




9750 ms. 


T9 


T9/R8 




9772 ms. 


T9 


T9/R8,T7/R10 


T7 completes 
I/O 


9781 ms. 


T7 


T7/R10 


T9 suspends for 
for I/O 


9800 ms. 


T7 


T7/R10 




9850 ms. 


T7 


T7/R10 




9894 ms. 


T9 


T9/R8 f T7/RlO 


T9 completes 
I/O 


9900 ms. 


T9 


T9/R8,T7/R10 




9981 ms. 


T7 


T7/R10 


T9 teminates 



Notes: 

T~. TT has an assigned priority of RIO 

2. T8 has an assigned priority of R9 

3. T9 has an assigned priority of R8 

Figure C-3 Task Sentry Operation 
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C.5 SUMMARY OF SCHEDULER OPERATION 

The four modes of scheduler operation are summarized in Figure C- 
4. The modes in which either time slicing or task sentry are 
described in the previous paragraphs. The scheduler mode in 
which both time slicing and task sentry are used, acts like the 
time-slicing-only mode for lists with more than one task, and 
like task sentry only for lists of just one task, providing that 
the task sentry value is greater than the time slice value. This 
is because the task sentry timer is reset each time a new task is 
allowed a time slice. In the simplest scheduler mode neither 
time slicing nor task sentry is used. In any case, the highest 
priority task in the system is always in execution. 

Most industrial applications use time slicing only or neither 
time slicing nor task sentry. If timesharing, scientific 
programming, or other general purpose data processing functions 
are performed on the same machine with a real-time control 
function, the time-slicing-only mode should be used. In this 
case, the general purpose data processing functions can be 
carried out on priority levels 1-3, and the control programs can 
occupy priority levels R1-R127. If each control task is assigned 
a different priority level, no time slicing of the real-time 
control tasks occurs. The general purpose DP functions are 
allowed to use any CPU time not required for the real time 
control function. If only real-time control is carried out by 
the CPU, neither time slicing mode nor task sentry mode should be 
used. In this case, all tasks are assigned a separate priority 
level. Execution is nearly the same as described above for Rl- 
R127 tasks but there is slightly less system overhead since the 
operating system no longer performs the time slicing function. 
In critical response environments, this mode may provide the 
extra fraction of a second response required. Because of the 
response characterisitics of the real-time priorities, 
communications software is frequently given a real time priority. 
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Task Sentry 



YES 



NO 



YES 



NO 



At end of time slice, task 
is put on the bottom of 
the list for its priority 
level. If a task executes 
more consecutive system 
time units than specified 
for the task sentry, then 
the task is placed at the 
bottom of the next lowest 
priority list in the 
active queue. 



If a task executes more 
consecutive system time 
units than specified for 
the task sentry, the 
task is placed at the 
bottom of the next lowest 
priority list in the 
active queue. 



At end of time slice, task 
is put at the bottom of 
the list for its priority 
level . 



Highest priority task has 
CPU as long as it wants it. 



Figure C-4 Summary of Scheduler Operation 



NOTE 



The highest 
executed. 



priority task is ALWAYS being 



C.6 SUPERVISOR CALLS AFFECTING SCHEDULER OPERATION 



Another feature that is useful in the industri 
environment is the Do Not Suspend supervisor call 
the SVC causes the task scheduler to be inhibited 
the task making the call. This is the only way to 
scheduler functions. Suspension is inhibiti 

milliseconds or a specified number of system t 
milliseconds. to 12.750 seconds). The task can 
by executing an I/O, Time Delay, Wait for I/O, or 
Wait supervisor call. This should be used in plac 
instruction. 



al application 

Execution of 

from suspending 

override the 

ed either 200 

ime units (50 

suspend itself 

Unconditional 

e of the LIMI 
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The following supervisor calls also affect scheduler operation: 

* Execute Task — Causes the initiation of a task that has 
been installed on any program file. 

* Activate Suspended Task — Reactivates a task that has 
placed itself in a suspended state by using the 
Unconditional Wait supervisor call. 

* Scheduled Bid Task — Activates a task at a specified 
time. 

* Time Delay — Suspends the calling task for the 
specified number of full system time units. 

* Change Priority — Changes the priority of the calling 
task. 

* Unconditional Wait — Suspends the calling task 
indefinitely. 

* Activate Time Delay Task — Activates a specified task 
that is in time delay. 
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Appendix D 

Device States and Luno Assignment 

Devices supported by DX10 have three possible states: online, 
offline, and diagnostic. When a device is offline, no LUNO can 
be assigned to it. When a device is in the diagnostic state, 
FUTIL sub-opcode >94 must be used when assigning a LUNO to that 
device. 
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Appendix E 
VDT Character Input SVCs 



E.l INTRODUCTION 

Two supervisor calls (SVCs) are available to write a character 
from a specified VDT keyboard. They are SVC >08 and SVC >18. 
Since these SVCs are optional in DX10 release 3.5, refer to your 
system generation documentation to verify the existence of SVCs 
>08 and >18 on your system. 

E.l.l VDT Character Input Supervisor Call (Code >08) 

This supervisor call inputs a character from a specified station 
keyboard. The calling task is suspended until the character is 
transferred. The system places the character in the most 
significant byte of the task workspace register 0. 

The supervisor call block consists of three bytes, and need not 
be aligned on a word boundary. Byte contains the code, and the 
system returns a value in byte 1. Byte 2 contains the station 
number. When the system is unable to locate the station, it 
returns -1 in byte 1. When the station has not been opened in 
the character mode, or when power is off at the station, the 
system returns >80 in byte 1. Otherwise, the system returns zero 
in that byte. 

The VDT character input call block is formatted as follows: 

Hex. 
Byte 
* + * 

>00 | >08 | ERROR CODE | 
+ + + 

>02 | STATION NUMBER | 
* * 



The following is an example of coding for a supervisor call block 
for a character input from station keyboard supervisor call. The 
SVC says to input a character from station 2 and place the 
character in the most significant byte of workspace register 0: 

SCBC BYTE 8,0,2 
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E.1.2 VDT Conditional Character Input Supervisor Call (Code 
>18) 

This supervisor call writes a character from a specified station 
keyboard. When a character is entered, the function sets the 
equal bit (bit 2) of the status register to 1 and places the 
character in the most significant byte of workspace register 0. 
When a character is not entered, the function sets the equal bit 
of the status register to 0, indicating a not equal status. In 
either case, the function returns control to the calling task 
immediately. 

The supervisor call block consists of three bytes, and you do not 
need to align it on a word boundary. Byte contains the code, 
and the system returns a value in byte 1. Byte 2 contains the 
station number. When the system is unable to locate the station, 
it returns -1 in byte 1. When the station has not been opened in 
the character mode, or when power is off at the station, the 
system returns >80 in byte 1. Otherwise, the system returns zero 
in that byte. 

The VDT conditional character input call block is formatted as 
follows: 

Hex. 
Byte 



*. 



■+ * 



>Q I >18 | ERROR CODE I 
+ + _ + 

>02 J STATION NUMBER | 
* * 



The following is an example of coding for a supervisor call block 
for a conditional character input from station keyboard 
supervisor call. The SVC says to input a character from station 
5 and place it in the most significant byte of workspace register 
if a character has been entered at the keyboard: 

SCBT BYTE >18,0,5 
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Appendix F 
The System Level Debugger 



F.l GENERAL INFORMATION 

Use the system level Debugger for breakpointing and listing the 
contents of memory locations and registers when debugging the 
system root only. The primary purpose for the system level 
Debugger is to debug DSRs. The Debugger allows you to control a 
program's execution and examine intermediate results to determine 
exactly where problems are occurring. 



F.2 INCLUSION IN THE OPERATING SYSTEM 

The Debugger is system generated as the XOP 1 processor . In 
response to the prompt DEVICE TYPE?, press the Command key to 
enter the command mode. Next enter CHANGE for the change 
command, and the prompt PARAMETER TO BE CHANGED? appears. 
Respond by entering DEBUG. The system generation program then 
prompts you with DEBUG? (NO) . If you want to include the Debugger 
in the operating system, enter YES. You exclude the Debugger by 
entering NO or taking the default value at this point. After 
entering YES, enter BUILD to generate the configuration. 

Next, perform the Assemble and Link Generated System (ALGS) 
command . 



F.3 PREPARING THE DX10 SYSTEM DEBUGGER 

Prior to using the system level Debugger, you must modify the 

Debugger image to specify the target terminal. The default 

terminal specification is a 911 VDT to which global LUNO is 
assigned. 

F.3.1 Specifying the Interactive Terminal Type 

The value in location >0A6C within the system level Debugger 
determines the type of interactive terminal to be used. Consult 
your system linkmap for the location of the system level Debugger 
within the system image. The system level Debugger is module 
DEBUG in the system root. The following values indicate the 
terminal type: 
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— ASR/KSR 

2 — 913 VDT 

4 — 911 VDT 

6 — 940 EVT (9902 interface) 

8 -- 940 EVT (COMIF interface) 



NOTE 

The system level Debugger assumes the CRD 
address for a 911 VDT is >100. The CRU 
address used for 913 VDTs is >0C0, and the 
CRU address for ASR/KSR devices is >000. 
These CRU addresses can be modified to allow 
communication with other terminals. To do 
so, you must change the word locations 
immediately following the terminal type 
address (>0A6C) . 



F.4 ACTIVATING THE SYSTEM LEVEL DEBUGGER 

The system level Debugger is activated through XOP ljf 
breakpoints. The breakpoint may be hard coded in a module, m 
the system level Debugger can be activated by entering the 
breakpoint through the front panel. The following procedure 
activates the Debugger in this manner, if the system is in an 
idle state. 

1. Press HALT. 

2. Press PC under DISPLAY. 

3. Write down the address displayed. 

4. Press MA under ENTER. 

5. Press MDD. 

6. Write down the value displayed. 

7. Press CLR. 

8. Enter >2C40 in the display lights. 

9. Press MDE. 
10. Press RUN. 
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The Debugger activates. Use the Debugger to set the value 
step 6 back into the location of step 3. 



from 



F.5 LIST OF DEBUGGER COMMANDS 

When the Debugger is activated, it requests commands by 
displaying a question mark (?) on your screen. You can then 
enter one of the Debugger commands listed in Table F-l. Each 
Debugger command is specified by entering a single character. 
All command parameters are hexadecimal numbers displayed without 
the hex (>) sign. A number is automatically terminated after 4 
hexadecimal digits are entered. A number can also be terminated 
by a period. 



Table F-l List of Debugger Commands 



Command Description 

A Display/alter memory location — long distance 

B Set the breakpoint using offset 

C Display condition code in status register 

D Dump outside of memory space — long distance 

E Examine a range of memory, relative 

F Display/alter the next sequential memory location 

G Execute program being debugged 

H Set/reset 990/12 hardware breakpoints 

I Inspect a range of memory locations 

J Display all workspace registers 

L List all instruction breakpoints 

M Display/alter the contents of a memory address 

N Display/alter the contents of the next memory 

address 

O Set breakpoint offset 

P Display/alter program counter 

Q Quit Debugging session 

R Display /alter the contents of a workspace 

register 

S Set instruction breakpoint 

U Clear breakpoint 

W Display/alter workspace pointer 

X Execute single instruction 

Z Resume execution after breakpoint 

+ Hexadecimal sum 

Hexadecimal difference 

? Display menu of commands 
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F.5.1 A Command — Display /Alter Memory Location — 

Long Distance 

The A command allows you to display or alter a particular memory 
location long distance. 

Syntax: a yyyy bbbb oooo=xxxx zzzz 

Explanation: The yyyy is the memory address to be displayed. 
The bbbb is most often the beet bias, although it can represent 
the beet address of a task segment. If bbbb is a beet bias, the 
value of oooo must be >0000? but if bbbb is a beet address of a 
segment, oooo becomes the logical starting address of that 
segment in the task's address space. 

The original value of the memory location is xxxx, and zzzz 
represents your desired value change. The values of bbbb and 
oooo can be defaulted to their previous values. 

Example: ? A 5A34 0034 0000=C003 C004 

The example shows the memory address >5A34 that is to be 
displayed. it has a beet bias of >0034, therefore oooo must be 
>0000. The original value at the address is >C003, and that 
value becomes >C004 at the conclusion of the A command. 

E.5.2 B Command — Set the Breakpoint Using Offset 

The B command allows you to set an instruction breakpoint using 
an offset value from the O command. 

Syntax: ? b yyyy 

Explanation: The value you enter for yyyy sets your breakpoint 
at yyyy plus the offset value. 

Example: ? B 67F4 

If, in the example, you have previously created an offset value 
of >0100 with the command, you have now set a breakpoint at 
location >68F4. 



NOTE 

Unloading a breakpoint requires using the U 
command. The U command value you enter does 
not add the offset to the memory location 
value of the breakpoint. 
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F.5.3 C Command — Display Condition Code in Status Register 

The C command displays the contents of the status register 
(condition code) and allows you to modify those contents. 

Syntax: ? C 

C=xxxx yyyy 

Explanation: The xxxx represents the contents of the status 
register, and yyyy represents the value you wish to enter as the 
new contents of the status register (optional entry). 

Example: ? C 

C=C00F C10F 

The example lists the status register contents, >C00F. The 
contents are changed to >C10F. This sets bit 7 of the status 
register, placing the computer in the non-privileged mode. If 
you enter no value, the contents of the register are unchanged. 

F.5.4 D Command — Dump Outside of Memory Space — Long 
Distance 

The D command allows you to inspect a range of memory locations 
outside of the your allotted memory space. * Be aware that TILINE 
timeout can occur when you are using the D command. 

Syntax: ? D 1111 uuuu bbbb ssss 

Explanation: The lower memory boundary value is represented by 
1111, and the upper memory boundary is represented by uuuu. The 
value of bbbb most often represents a beet bias, although it can 
represent the beet address of a task segment. If bbbb is a beet 
bias, the value of ssss must be >0000; but if bbbb is a beet 
address of a segment, ssss becomes the logical starting address 
of that segment in the task's address space. The uuuu value is 
optional. If you donot include the uuuu value, the system dumps 
the next 16 words. If you do not specify a bbbb value, the 
command assumes the previous values of bbbb and ssss. 

Example: ? D 0382 

0382-0356 2BA2 0001 0000 0E4D 51F4 9562 0002 
0392-0077 0012 924A 0288 9562 3BB2 419E 0001 

The example lists the 16 words of memory specified by address 
>0382. Since no uuuu, or bbbb values are specified, only the 
next 16 words of memory are displayed. 
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F.5.5 E Command — Examine a Range of Memory, Relative 

The E command allows you to examine a range of memory locations 
using a relative address. Use the E command to examine a block 
of data that can be thought of as one unit, such as a Physical 
Record Block (PRB) . 



Syntax: 



? E 1111 uuuu 



Explanation: The lower memory boundary value is represented by 
1111 plus the offset from the command, and the upper memory 
boundary is represented by uuuu plus the offset. The uuuu value 
is optional. If you chose not to specify a value for uuuu, the 
system displays the values from 1111 (plus the offset value) to 
1111 (plus the offset value) plus eight. 



Example: 



? E 0312 



0392-035 6 2BA2 0001 0000 0E4D 51F4 9562 0002 



If, in the example, you had previously assigned an offset value 
of >0080 with the command, the E command adds >0312 and >008 
to find the memory location that you want to examine (>0392) . 
Since no uuuu value is specified, only 8 words of memory are 
displayed. 



NOTE 

Unloading a breakpoint requires using the U 
command. The U command value you enter does 
not add the offset to the memory location 
value of the breakpoint. 



F.5.6 F Command — Display /Alter Next Sequential Memory 

Location — Long Distance 

The F command allows you to display or alter the next memorv 
location. 



Syntax: 



? F wwww=xxxx yyyy 
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Explanation: The wwww value is the location being displayed, and 
xxxx represents the value in that location. The change value 
yyyy is the value you* enter to modify xxxx. The instruction uses 
the current map bias. 

Example: ? F A555=03B2 03C2 

The example shows that memory address >A555 contains >03B2 
currently, but >03C2 replaces that value upon completion of the 
command . 



F.5.7 G Command — Execute Program Being Debugged 

The G command executes the program currently being debugged. Use 
it to start the program initially, and to proceed from a 
breakpoint. It is identical bo the Z command when used to 
restart the program. 

Syntax: ? G 

Explanation: This command does not require parameters. 

Example: ? G 

The example initiates execution of the user program. Use the G 
command to start the program, or in some cases, to restart the 
program after stopping to examine the register contents. 

F.5.8 H Command — Set/Reset 990/12 Hardware Breakpoint 

The H command allows you to set or reset a 990/12 hardware 
breakpoint. This instruction is only applicable on systems using 
the 990/12 CPU. 

Syntax: ? H=xxxx yyyy m t 

Explanation: The xxxx value represents the address of an 
existing hardware breakpoint (displayed by the system) , and yyyy 
is the new logical address to be breakpointed. Blank means use 
current breakpoint and P0 means disable breakpoint. The m value 
is the map file to be breakpointed (0 or 1) . The m default is 0. 
The t value is the type of memory access to breakpoint. (R = 
READ, W = WRITE, I = INSTRUCTION FETCH, and A = ANY ACCESS. The 
default value is A.) 

Example: ? H=3516 358 6 OR 

The example changes the breakpoint from >3516 to >3586 using map 
file on a READ. 
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F.5.9 I Command — Inspect a Range of Memory Locations 

This command allows you to inspect a range of memory locations in 
the current address space. 

Syntax: ? I 1111 uuuu 

xxxx xxxx . . . xxxx yy yy • • • yy 

Explanation: The lower address of the memory locations to be 
displayed is represented by 1111. This is a required entry. The 
upper address of the memory locations to be displayed, an 
optional entry, is represented by uuuu. If you do not specify 
1111 and uuuu, the Debugger displays the locations displays the 
locations pointed to by the current PC (1111 through 1111 + >1E) . 
A warning message is displayed indicating that you have entered 
an illegal hexadecimal value if you fail to specify either 
address. Each xxxx is the displayed hexadecimal contents of a 
memory location. Each yy is the ASCII representation of the 
memory contents. The command displays >10 bytes per line, and 
fills the line of the display on which uuuu is displayed. That 
is, the command always displays a multiple of >10 bytes. 

Example: ? I C000 C020 

2202 0006 0800 ...5336 ■ S6 

0045 3132 3658 ...0000 .E 12 6X 

3148 4444 2634 ...5541 1H DD* &4 ... UA 

The example displays the memory locations from >C000 to >C020. 
Memory location >C000 contains >220 2, location >C00 2 contains 
>0006, and so on. Location >C020 contains >3148. The memory 
locations up to and including location >C02F are displayed, 
filling out the line in the example. 
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F.5.10 J Command — Show All Local Workspace Registers 

The J command displays all local workspace registers on one line 
of the display. 

Syntax: ? J 

xxxx xxxx xxxx . . . xxxx 

Explanation: This command does not require parameters. Each 
xxxx is the value in one of the workspace registers, RO through 
R15. 

Example: ? J 

0002 4AC7 0000 0000 ... 0000 

The example list the contents of all the workspace registers. 
Workspace register contains >0002, workspace register 1 
contains >4AC7, and so on. The listing displays all 16 workspace 
registers. 

F.5.11 L Command — Lists All -Breakpoints 

This command lists the logical addresses of all breakpoints 
currently set in the program. 

Syntax: ? L 

LOCATION 

xxxx 

xxxx 

Explanation: This command requires no parameters. Each xxxx is 
the displayed location of a breakpoint. 

Example: ? L 

LOCATION 

B610 

BC24 

The example shows the two breakpoints that have been set in the 
program, at locations >B610 and >BC24. 
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F.5.12 M Command — Display/Alter Contents of Memory Address 



The M command displays and 
specified memory location, 
the task space may be modified 



allows you to alter the contents of a 
Only addresses currently mapped in 
with this command. 



Syntax: 



? M nnnn 



M nnnn=xxxx yyyy 

Explanation: In this syntax, nnnn is the word address of the 
memory location you want to display. It is a required entry. 
When nnnn is an odd byte, the memory word at nnnn-1 is displayed. 
The displayed value of the memory address is represented by xxxx, 
and yyyy is the new value you want to place in the memory address 
{optional entry) . 



Example : 



? M B680 



M B680=A00 2 A00 3 



The example displays the contents of memory location >B680. The 
value in that location is >A00 2, and the contents are chanqed to 
>A00 3. * 



F.5.13 
Address 



N Command — Display/Alter Contents of ■ Next Memory 



The N command allows you to display and alter the contents of the 
next memory address after the previously examined address. This 
command is used in connection with the M, N, or R commands. 



Syntax: 



? N nnnn=xxxx yyyy 



Explanation: In this syntax, nnnn is the displayed address of 
the next location, xxxx represents the displayed value of the 
next location, and yyyy is the new value you want to place in the 
memory location (an optional entry). 
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Example: ? R4=00 22 

? N BOOE=04 00 0800 

This example shows an R command and an N command. The R command 
displays workspace register 4. The N command displays the 
contents of the next memory address. In this example, the next 
memory address is workspace register 5, at location >B00E. The 
value in the workspace register,- >04 00, is changed to >08 00. 

F.5.14 Command — Set Offset 

The command sets the offset for use by the E and B commands. 

Syntax: ? 0=xxxx yyyy 

Explanation: The xxxx value displayed is the current relative 
address for the offset and can be changed by entering the desired 
value yyyy. 

Example: ? 0=2 8DE 09 00 

The example changes the offset for the B or E commands from >28DE 
to >0900. 

P. 5. 15 P Command — Display/Alter the Program Counter 

The P command displays the contents of the program counter. You 

can alter the contents of the program counter if you so desire. 

Syntax: ? P 

PC=xxxx yyyy 

Explanation: The current program counter value is represented by 
xxxx, and yyyy represents the value to replace the currently 
displayed value (optional) . 
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Example: ? P 

PC=BA20 BA2C 

The example displays >BA20 as the program counter contents. The 
contents are then changed to >BA2C. 

F.5.16 Q Command — Quit Debug Session 

Use the Q command to terminate a Debug session. 

Syntax: ? Q 

END DEBUG. 
Explanation: This command does not require any parameters. 
Example: ? Q 

END DEBUG. 

The message indicates that the systyem is in an idle state. If 
you want to exit from the Debugger entirely, enter a G command. 

F.5.17 R Command — Display /Alter Workspace Register 

The R command displays the contents of a workspace register. You 
can alter these contents if you so desire. 

Syntax: ? Rn=xxxx yyyy 

Explanation: The n represents the workspace register, from to 
F. This is a required entry. The xxxx represents the displayed 
workspace register contents, and yyyy is the value that replaces 
the displayed contents (optional entry). 
Example: ? R4=2A60 2A64 

The example displays the contents of workspace register 4 which 
is >2A60. That value is then changed to >2A64. 
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F.5.18 S Command — Set Breakpoint 

Use the S command to set an instruction breakpoint at any address 
currently mapped in the task space. When the breakpoint is 
reached, the contents of all current workspace registers (0 
through 15) are displayed, along with the current PC. 

Syntax: ? S yyyy 

Explanation: The yyyy represents the address for the instruction 
breakpoint. The yyyy value is a required entry. 

Example: ? S COO 6 

The example sets a breakpoint at memory location >C006. When the 
task is executed, it stops at location >C006 to allow you to 
examine registers, memory, and so on. You can make necessary 
changes at this point. The following values are displayed at a 
breakpoint: 

BRKPT AT COO 6 

0000 23C0 1000 3348 4566 7290 0000 ... 2448 

The first line of the display shows the current program counter 
value. The second line in the display shows the contents of the 
16 workspace registers, through 15. 

F.5.19 U Command — Clear a Breakpoint 

The U command clears (removes) one or all instruction 
breakpoints. 

Syntax: ? u yyyy 

Explanation: The yyyy represents the location of the breakpoint 
that is to be removed. This is an optional entry. If you do not 
enter a value for yyyy, all breakpoints are removed. 



9 3915 3-9701 F-13 



The System Level Debugger System Design Document 



Example: ? U COO 6 

The example deletes an instruction breakpoint set at memory 
location >C006. 



NOTE 

Unloading a breakpoint does not consider the 
offset value you may have added using the 
command. Therefore the value of yyyy is the 
sum of the address from which you want to 
delete the breakpoint and the offset value. 



F.5.20 W Command — Display /Alter Workspace Pointer 

The W command displays the contents of the workspace pointer. 
You can alter these contents if you then wish. 

Syntax: ? W=xxxx yyyy 

Explanation: The value represented by xxxx is the displayed 
workspace pointer contents. The yyyy value is the optional 
replacement value for xxxx. 

Example: ? W=B010 BO 30 

The example displays the contents of the workspace pointer, which 
is >B010. The displayed contents are then changed to >B030. 
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F.5.21 X Command — Execute a Single Instruction 

The X command allows you to step through the program being 
debugged one instruction at a time. The contents of all current 
workspace registers are displayed after executing each 
instruction. The X command executes the instruction at the 
address in the program counter. 



Syntax: 



? X 



BRKPT AT xxxx 



rrrr rrrr rrrr 



rrrr 



Explanation: This command requires no parameters from you. The 
xxxx value represents the displayed contents of the program 
counter. Each rrrr is the displayed contents of one of the 
workspace registers, through 15. 



Example; 



? X 

BRKPT AT B250 
0002 A020 0000 



0000 



The example illustrates an X command executing the instruction at 
the address in the program counter. The new program counter 
address, >B250, and the contents of the workspace registers are 
displayed. Workspace register contains >0002, workspace 
register 1 contains >A020, and so on. 

P. 5.22 Z Command — Resume Execution After Breakpoint 

When you enter the Z command, execution proceeds from the current 
breakpoint to the next breakpoint if one is present. The 
breakpoint is not cleared, and can be used again, unless you 
enter a U command. 

Syntax: ? z 

Explanation: This command requires no parameters from you. 

Example: ? z 

This example restarts program execution after it has stopped at a 
breakpoint. Use the Z command after a breakpoint is reached, and 
after you have examined and changed memory, register contents, 
and so on, as necessary. 
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F.5.2 3 + Command — Add Hexadecimal Numbers 

Use the Plus (+) command to display the hexadecimal sum of two 
hexadecimal numbers. 

Syntax: ? + xxxx yyyy = zzzz 

Explanation: The xxxx value is a hexadecimal number (required 
entry), and yyyy is a hexadecimal number to be added ,to xxxx; 
(yyyy is also a required entry) . The hexadecimal sum of xxxx + 
yyyy is represented by zzzz. 

Example: ? + C420 2184 = E5A4 

The example adds >C420 to >2184 and displays the sum of >E5A4. 

F.5.24 - Command — Subtract Hexadecimal Numbers 

Use the Minus (-) command to display the hexadecimal difference 
of two hexadecimal numbers. 



Syntax: ? - xxxx yyyy = zzzz 



4 



Explanation: The xxxx value is a hexadecimal number (requii 
entry), and yyyy the hexadecimal number that xxxx is to 
subtracted from; (yyyy is also a required entry). The 
hexadecimal difference of yyyy - xxxx is represented by zzzz. 

Example: ? - 0048 21CE = 2186 

The example subtracts >004 8 from >21CE and displays the 
difference of >2186. .. 
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F.5.25 



Command — Display a Menu of Commands 



Use the ? command to display a- menu of all available Debug 
commands, showing the format of each command and giving a brief 
description of each. 



Syntax: 

Explanation: 

Example: 



? ? 

This command requires no parameters from you. 



•? •? 



P PROGRAM COUNTER 

W WORKSPACE POINTER 

C STATUS REGISTER 

R MODIFY WORKSPACE REGISTER 

M MODIFY MEMORY WORD 

A ALTER A MEMORY LOCATION - LONG DISTANCE 

I INSPECT MEMORY 

SET BREAKPOINT OFFSET 

E EXAMINE A RANGE OF MEMORY LOCATIONS, RELATIVE 

D DUMP A RANGE OF MEMORY OUTSIDE OF ADDRESS SPACE 

J DUMP ALL REGISTERS 

S SET BREAKPOINT 

B SET BREAKPOINT USING OFFSET 

U REMOVE BREAKPOINTS 

L LIST ALL BREAKPOINTS 

G EXECUTE PROGRAM BEING DEBUGGED 

X SINGLE STEP PROGRAM 

Z CONTINUE EXECUTION AFTER BREAKPOINT 

N DISPLAY NEXT WORD 

F DISPLAY/ALTER' NEXT SEQUENTIAL MEMORY LOCATION - 

LONG DISTANCE 

Q QUIT DEBUGGER? 

H SET/RESET 990/12 HARDWARE BREAKPOINTS 

+ ADD 

SUBTRACT 

? DISPLAY MENU OF COMMANDS 

You can select any of the commands or exit from the Debugger by 
entering Q, waiting for the END DEBUG response, then entering the 
G command . 
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